Google 검색: mysql-4.0리플리케이션
* 기본 개론
- 각종 DB를 사용하다 보면 데이터의 무결성 만큼 중요한 문제는 장애 발생시 대처할 수 있는 백업 데이터의 필요성이다.
이는 서비스중이 아니더라도 각종 테스트시에 잘못 날린 쿼리로 인하여 데이터의 손실이 발생할시에 따른 여러가지 가능성이 존재하기때문에 DB의 백업여부는 항상 중요하다.
보통 DB의 데이터 보존 방법에는 데이터 파일 덤프나 Replication을 사용하게 되는데 이는 각각의 장,단점이 존재한다.
- 각종 DB를 사용하다 보면 데이터의 무결성 만큼 중요한 문제는 장애 발생시 대처할 수 있는 백업 데이터의 필요성이다.
이는 서비스중이 아니더라도 각종 테스트시에 잘못 날린 쿼리로 인하여 데이터의 손실이 발생할시에 따른 여러가지 가능성이 존재하기때문에 DB의 백업여부는 항상 중요하다.
보통 DB의 데이터 보존 방법에는 데이터 파일 덤프나 Replication을 사용하게 되는데 이는 각각의 장,단점이 존재한다.
데이터 파일 덤프시 장단점
1) 문제가 발생할 시 특정 시점으로의 복원이 가능하다.
2) 한번 덤프를 받을시 데이터가 많을수록 덤프시간이 늘어난다.
3) 한번 덤프를 받아놓은것들이 누적되면 용량이 장난아니게 불어난다.
Replication을 이용한 데이터 백업
1) 실시간으로 데이터 백업을 하기때문에 원본 DB에 문제가 발생했을때 즉각적인 대처가 가능하다.
2) 특정시점으로의 복원은 불가능하다.
3) Replication시에 사용되는 log를 주기적으로 관리해줘야 용량의 압박에서 벗어날 수 있다.
위에서 보면 실시간 백업 과 특정시점에의 백업의 차이가 있다.
따라서 보통 2가지의 백업방식을 동시에 쓰는 경우가 많으며, 장애의 종류의 따라서 DB복원의 종류를 선택해서 사용한다.
1) 문제가 발생할 시 특정 시점으로의 복원이 가능하다.
2) 한번 덤프를 받을시 데이터가 많을수록 덤프시간이 늘어난다.
3) 한번 덤프를 받아놓은것들이 누적되면 용량이 장난아니게 불어난다.
Replication을 이용한 데이터 백업
1) 실시간으로 데이터 백업을 하기때문에 원본 DB에 문제가 발생했을때 즉각적인 대처가 가능하다.
2) 특정시점으로의 복원은 불가능하다.
3) Replication시에 사용되는 log를 주기적으로 관리해줘야 용량의 압박에서 벗어날 수 있다.
위에서 보면 실시간 백업 과 특정시점에의 백업의 차이가 있다.
따라서 보통 2가지의 백업방식을 동시에 쓰는 경우가 많으며, 장애의 종류의 따라서 DB복원의 종류를 선택해서 사용한다.
- Replication의 경우 위에 얘기한 백업이외의 다른 장점이 있다.
원본 DB와 백업DB의 데이터가 일치 하기때문에 두 DB를 사용하여 데이터 분산처리를 할 수있다. 즉 원본 DB에서는 insert,update등을 처리해주고 백업 DB에서는 select 와 같은 read only 작업을 통해서 DB서버의 부하를 줄여줄 수 있다.
* Mysql Replication의 기본 구조
1) Master(원본DB), Slave(백업DB)로 각 DB를 같은 DB내용으로 구성함
2) MasterDB는 자신에게서 일어나는 모든 작업내용을 바이너리 로그에 기록함.
3) SlaveDB는 Master에 접속을 해서 Master의 바이너리 로그를 읽으면 변경사항을 가져온후 자신에게 그 내용을 적용시킴.
* 셋팅 방법 1) Master와 Slave의 설치
- 안정성을 위해서 두대의 DB서버의 버전을 동일하게 맞추어 주는것이 좋다. Replication은 3.23.15부터 지원되고 있다.
2) Master계정 생성
- Slave에서 Master로 접속할수 있는 권한의 계정을 만들어주어야 한다. 기존의 계정에 추가적으로 권한을 주어도 상관은 없으나 되도록이면 새로 계정을 만들어 추가적인 접근을 막는것이 좋다.
- 4.0.2 이전 버전의 MySQL에서는, REPLICATION SLAVE 권한이 없으므로, 다음과 같이 FILE 권한으로 대신한다.
3) MasterDB 백업 및 복구
- Master서버의 데이터를 백업 받아 Slave서버에서 복구 시킨다.
- 백업 방법은 MyISM방식의 경우 data디렉토리안에 각각의 디렉토리를 복사해서 옮기면 되며, innoDB의 경우 mysqldump를 이용하여 백업한후 Slave에서 복원시킨다.
4) Master 환경설정
- Master서버의 my.cnf (일반적으로 /usr/local/mysql/etc/ 나 /etc/에 존재한다.)를 다음과 같이 수정한다.
5) Slave 환경설정
- Master와 동일하게 my.cnf를 연다.
6) Master 및 Slave 기동
- Master를 먼저 시작시킨후 Slave를 시작시킨다.
7) 확인
- Master에서 아래와 같이 확인을 할 수 있다.
원본 DB와 백업DB의 데이터가 일치 하기때문에 두 DB를 사용하여 데이터 분산처리를 할 수있다. 즉 원본 DB에서는 insert,update등을 처리해주고 백업 DB에서는 select 와 같은 read only 작업을 통해서 DB서버의 부하를 줄여줄 수 있다.
* Mysql Replication의 기본 구조
1) Master(원본DB), Slave(백업DB)로 각 DB를 같은 DB내용으로 구성함
2) MasterDB는 자신에게서 일어나는 모든 작업내용을 바이너리 로그에 기록함.
3) SlaveDB는 Master에 접속을 해서 Master의 바이너리 로그를 읽으면 변경사항을 가져온후 자신에게 그 내용을 적용시킴.
* 셋팅 방법 1) Master와 Slave의 설치
- 안정성을 위해서 두대의 DB서버의 버전을 동일하게 맞추어 주는것이 좋다. Replication은 3.23.15부터 지원되고 있다.
2) Master계정 생성
- Slave에서 Master로 접속할수 있는 권한의 계정을 만들어주어야 한다. 기존의 계정에 추가적으로 권한을 주어도 상관은 없으나 되도록이면 새로 계정을 만들어 추가적인 접근을 막는것이 좋다.
master mysql > GRANT REPLICATION SLAVE ON *.*
-> TO 'user_name'@'user_host' IDENTIFIED BY 'user_password';
-> TO 'user_name'@'user_host' IDENTIFIED BY 'user_password';
- 4.0.2 이전 버전의 MySQL에서는, REPLICATION SLAVE 권한이 없으므로, 다음과 같이 FILE 권한으로 대신한다.
master mysql > GRANT FILE ON *.*
-> TO 'user_name'@'user_host' IDENTIFIED BY 'user_password';
-> TO 'user_name'@'user_host' IDENTIFIED BY 'user_password';
3) MasterDB 백업 및 복구
- Master서버의 데이터를 백업 받아 Slave서버에서 복구 시킨다.
- 백업 방법은 MyISM방식의 경우 data디렉토리안에 각각의 디렉토리를 복사해서 옮기면 되며, innoDB의 경우 mysqldump를 이용하여 백업한후 Slave에서 복원시킨다.
4) Master 환경설정
- Master서버의 my.cnf (일반적으로 /usr/local/mysql/etc/ 나 /etc/에 존재한다.)를 다음과 같이 수정한다.
[mysqld]
log-bin = /mysqltemp/log/replication.log --> 파일경로/파일이름 . 입력하지 않으면 기본 디렉토리에 생성된다.
server-id = 1 --> 이 번호는 master의 경우 일반적으로 1번이며, slave와 구분된 번호를 사용해야 한다.
binlog-do-db = 데이터베이스 1 --> Mysql 데이터 베이스중 Replication할 데이터베이스를 적어둔다.
binlog-do-db = 데이터베이스 2 --> 추가적인 데이터베이스는 아래와 같이 계속 붙여서 적어준다.
log-bin = /mysqltemp/log/replication.log --> 파일경로/파일이름 . 입력하지 않으면 기본 디렉토리에 생성된다.
server-id = 1 --> 이 번호는 master의 경우 일반적으로 1번이며, slave와 구분된 번호를 사용해야 한다.
binlog-do-db = 데이터베이스 1 --> Mysql 데이터 베이스중 Replication할 데이터베이스를 적어둔다.
binlog-do-db = 데이터베이스 2 --> 추가적인 데이터베이스는 아래와 같이 계속 붙여서 적어준다.
5) Slave 환경설정
- Master와 동일하게 my.cnf를 연다.
[mysqld]
server-id = 2 --> 마스터와 숫자가 틀리면 된다.
master-host = xxx.xxx.xxx.xxx --> 마스터의 IP
master-user = xxxx --> 리플리케이션용 ID
master-password = xxxx --> 패스워드
replicate-do-db = 가져올 데이터베이스1 --> 마스터에서 설정한 데이터베이스 이름
replicate-do-db = 가져올 데이터베이스2 --> 상동
master-port = 3306 --> 접속할 포트번호 (일반적인 포트 3306)
server-id = 2 --> 마스터와 숫자가 틀리면 된다.
master-host = xxx.xxx.xxx.xxx --> 마스터의 IP
master-user = xxxx --> 리플리케이션용 ID
master-password = xxxx --> 패스워드
replicate-do-db = 가져올 데이터베이스1 --> 마스터에서 설정한 데이터베이스 이름
replicate-do-db = 가져올 데이터베이스2 --> 상동
master-port = 3306 --> 접속할 포트번호 (일반적인 포트 3306)
6) Master 및 Slave 기동
- Master를 먼저 시작시킨후 Slave를 시작시킨다.
7) 확인
- Master에서 아래와 같이 확인을 할 수 있다.
mysql> show processlist;
| 21315835 | cdn_slave | xxx.xxx.xxx.xxx:52531 | NULL |
Binlog Dump | 65 | Has sent all binlog to slave; waiting for binlog to be updated | NULL |
mysql> show master status;
+--------------------+----------+-------------------------+------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+--------------------+----------+-------------------------+------------------+
| replication.000012 | 88943948 | cfolder_common,fms_main | |
+--------------------+----------+-------------------------+------------------+
위에서 000012라는 파일을 현재 log로 이용하고 있는데 이경우 이전로그 파일은 삭제해도 무방하다고 한다.(아직 해보지 않았음)
다음은 Slave에서 확인을 해보자
mysql> show slave status;
+----------------------------------+----------------+-------------+-------------+---------------+--------------------+---------------------+-------------------------------+---------------+-----------------------+------------------+-------------------+-------------------------+---------------------+--------------------+------------------------+-------------------------+-----------------------------+------------+------------+--------------+---------------------+-----------------+-----------------+----------------+---------------+--------------------+--------------------+--------------------+-----------------+-------------------+----------------+-----------------------+
| Slave_IO_State | Master_Host | Master_User | Master_Port | Connect_Retry | Master_Log_File | Read_Master_Log_Pos | Relay_Log_File | Relay_Log_Pos | Relay_Master_Log_File | Slave_IO_Running | Slave_SQL_Running | Replicate_Do_DB | Replicate_Ignore_DB | Replicate_Do_Table | Replicate_Ignore_Table | Replicate_Wild_Do_Table | Replicate_Wild_Ignore_Table | Last_Errno | Last_Error | Skip_Counter | Exec_Master_Log_Pos | Relay_Log_Space | Until_Condition | Until_Log_File | Until_Log_Pos | Master_SSL_Allowed | Master_SSL_CA_File | Master_SSL_CA_Path | Master_SSL_Cert | Master_SSL_Cipher | Master_SSL_Key | Seconds_Behind_Master |
+----------------------------------+----------------+-------------+-------------+---------------+--------------------+---------------------+-------------------------------+---------------+-----------------------+------------------+-------------------+-------------------------+---------------------+--------------------+------------------------+-------------------------+-----------------------------+------------+------------+--------------+---------------------+-----------------+-----------------+----------------+---------------+--------------------+--------------------+--------------------+-----------------+-------------------+----------------+-----------------------+
| Waiting for master to send event | xxx.xxx.xx.xxx | cdn_slave | 3306 | 60 | replication.000012 | 90522050 | KRDAC1FLD001-relay-bin.000002 | 703738068 | replication.000001 | Yes | Yes | common,fms_main | | | | | | 0 | | 0 | 703738098 | 11902379162 | None | | 0 | No | | | | | | 0 |
+----------------------------------+----------------+-------------+-------------+---------------+--------------------+---------------------+-------------------------------+---------------+-----------------------+------------------+-------------------+-------------------------+---------------------+--------------------+------------------------+-------------------------+-----------------------------+------------+------------+--------------+---------------------+-----------------+-----------------+----------------+---------------+--------------------+--------------------+--------------------+-----------------+-------------------+----------------+-----------------------+
먼가 엄청 길게 되어있는데 여기서 우리가 주의를 두고 보아야 될것은 Master의 포지션과 Slave의 Read_Master_Log_Pos가 동일한 지점에 있어야 한다는 것이다. 위의
예제는 화면을 가져오는사이에 그만큼의 차이가 낫을뿐이며 정상적인 상태로는 항상 동일한 값과 동일한 파일명을 가지고 있다.
8 ) 기타
- Master에서 Create Database 는 Slave에 반영되지 않는다.
- 서버의 환경이 변경되거나 계정이 바뀐후에 my.cnf만 수정해서는 그 내용이 반영되지 않는다. 데이터 디렉토리 안에 master.info를 변경해주거나 이 파일을 제거해준후 재시작을 해주어야 한다.
- 로그의 포지션에 관한 기본정보는 relay-log.info파일에 있으며 이는 시작지점을 나타낸다.
- Master의 Replication로그나 Slave의 relay-bin로그는 vi로는 읽을수 없으며 아래와 같은 방법으로 변환후에 읽을 수 있다.
- Master에서 Create Database 는 Slave에 반영되지 않는다.
- 서버의 환경이 변경되거나 계정이 바뀐후에 my.cnf만 수정해서는 그 내용이 반영되지 않는다. 데이터 디렉토리 안에 master.info를 변경해주거나 이 파일을 제거해준후 재시작을 해주어야 한다.
- 로그의 포지션에 관한 기본정보는 relay-log.info파일에 있으며 이는 시작지점을 나타낸다.
- Master의 Replication로그나 Slave의 relay-bin로그는 vi로는 읽을수 없으며 아래와 같은 방법으로 변환후에 읽을 수 있다.
mysqlbinlog KRDAC1FLD001-relay-bin.000002 > aaa.sql
댓글 없음:
댓글 쓰기