mysql replication 리플리케이션

Mysql replication (Mysql 5.X)

개요

Mysql 에서 제공하는 master - slave 혹은 master - master 동기화를 위한 솔루션인듯 하다. 일단 Master - Master 로 셋팅을 해봤는데 일단 접속량이 많지 않고 장애가 발생하지 않는 가정하에서는  잘된다. 정확히 따지자면 Master - Slave 가 정확한 의미인듯 하다. 하지만 리플리케이션이 깨지는 경우를 많이 봐와서 신뢰할만한 것인지는 모르겠다. 기본적으로 하나의 Insert 서버를 마스터로 하고 다수의 Slave select 서버들을 구성하는게 낫다고들 함.

보완해야 할 사항

리플리케이션의 경우 깨지는 경우 슬레이브가 문제가 됨. 복구하기 힘듬

마스터가 DB 데몬이 중단되거나 서버 장애시 슬레이브는 릴레이로그를 받지 못하기 때문에 마스터의 DB가

삭제 및 변경 파괴되지 않는 이상 장애시 까지는 마스터와 슬레이브간 DB는 동일할거라 판단됨.

슬레이브 서버 문제 발생하여 DB 데몬이나 서버 다운되더라도 마스터는 상관없이 계속 릴레이 로그를 남기면서

유지한다. 슬레이브 서버는 실시간으로 로그를 받지 못하며 슬레이브가 복구시 마스터의 DB와 슬레이브의 DB가

불일치 하게 된다. rsync 처럼 그동안 발생한 로그들 자동으로 받아오는 그런 솔루션은 아닌듯 함.

마스터 - 마스터로 구성한 경우 서로 꼬이게 되는 경우 대략 100% 장애 복구는 힘들거 같기도 함...

 

Master1 192.168.0.1

Master2 192.168.0.2

일단 DB간에 상대편 아이피에 대한 계정설정을 해준다.

grant REPLICATION SLAVE on *.* to 'repluser'@'%' IDENTIFIED BY 'repluser';
 - %를 넣어주면 어느 아이피에서든지 repluser 라는 계정으로 접속 가능하기 때문에 나는 아래와 같이 했다.
 - Master1 에서는 Master2의 아이피를 넣어주고 서로 교차되게끔 명령어를 날려준다.
 - ID 와 PW는 repluser 로 셋팅되었다.
 - *.* 모든 DB를 나타내는듯 함 (리플리케이션을 할 DB 이름이나 *.* 를 적어주는듯 함)

 
GRANT REPLICATION SLAVE  ON *.* TO repluser@192.168.0.2 IDENTIFIED BY 'repluser';

리플리케이션 설정파일

/etc/my.cnf  (대충 아래를 보면 이해가 될거다)

db=디비명(테이블) : 테이블만도 리플리케이션 가능함

Master1

server-id = 1 master-host = 192.168.0.2 master-port = 3306 master-user = repliuser master-password = repliuser binlog-do-db = www binlog-ignore-db=information_schema binlog-ignore-db=mysql binlog-ignore-db=test relay-log master-repl-bin master-connect-retry = 5

 

Master2

server-id = 2 master-host = 192.168.0.1 master-user = repliuser master-password = repliuser master-port = 3306 binlog-do-db = www binlog-ignore-db=information_schema binlog-ignore-db=mysql binlog-ignore-db=test relay-log slave-repl-bin master-connect-retry = 5

 
 

인터넷에 찾아보니 각각 Master, Slave 순으로 시작을 하라는데 둘다 Master - Master 라서 아무거나 먼저 시작을 했다.

그냥 mysql DB가 기존에 운영되던 거라면 에러가 뜰것인데 나같은 경우는 그냥 간단하게

서버 2대간에 mysql 의 Bin 로그와 relay 로그를 삭제하고 각자 시작을 해주니 에러가 뜨지 않았다.

그리고 리플리케이션 시작 및 정지를 반복했다면 mysql/data 디렉토리에 아래의 파일들이 있다.

아무리 my.cnf 파일을 변경해주고 재시작해도 반영이 되지 않았는데 아마 밑에 info 파일들이 존재하면

my.cnf 파일의 정보를 보지도 않고 시작되는듯 하여 밑의 파일을 삭제후 다시 시작하니깐 아래 파일들이

다시 생성되면서 문제 없이 진행되었다.

 
/usr/local/mysql/data/master.info
  - 마스터 서버의 로그인 정보? (즉 파일이 존재하는 서버의 자기 자신의 정보를 이야기 하는듯 )

/usr/local/mysql/data/relay-log.info
 - 마지막으로 업데이트 된 바이러니 로그?

로그파일

 
bin.000X : 자기 자신 마스터의 바이너리 로그
relay-bin.000X : 마스터로 부터 업데이트 되는 바이러니 로그 (즉 상대편 바이러니 로그를 참조하여 릴레이로그 생성함)

 

리플리케이션 상태보기

SHOW MASTER STATUS\G
 - 마스터 서버의 상태 보기 즉 자기 자신의 상태를 의미하는듯 함
 
File: mysql-bin.000018    <--- 현재 기록되고 있는 바이너리 파일 
Position: 838408022         <--- 현재 포지션 번호 (같은시간대 slave도 동일한 숫자여야함)
Binlog_Do_DB:                  <--- 현재 모든 DB를 대상으로 리플리케이션 하고 있어
Binlog_Ignore_DB:            <--- 공란으로 표시됩니다.

SHOW SLAVE STATUS\G
 - 슬레이브 서버 상태 보기, 즉 자신이 슬레이브가 되어 상대편 마스터와의 상태를 보는듯함

 
Slave_IO_State: Waiting for master to send event   <--- IO_State 에서 이렇게 표시되어 있으면 정상적으로 
                                                                                                            Master와 통신하고 있는 것임.

Master_Host: 192.168.0.2                               <--- Master 호스트 IP 
Master_User: repluser                                     <--- Master 에 접근할 DB 계정
Master_Port: 3306                                            <--- Master DB 포트 
Connect_Retry: 5                                             <--- 위에서 부터 4개값은 my.cnf에 기재되어 있음
Master_Log_File: mysql-bin.000018                     <--- 참조하고 있는 Master 바이너리 파일 
Read_Master_Log_Pos: 838408260                     <--- 참조하고 있는 Master Log 포지션 번호 (같은시간대 Master와 동일한 숫자여야함)
             Relay_Log_File: db_slave1-relay-bin.000034  <--- Slave에 기록되고 있는 릴레이 로그 파일
              Relay_Log_Pos: 838408397                          
      Relay_Master_Log_File: mysql-bin.000018       <--- 릴레이하고 있는 Master 바이너리 로그 파일 
           Slave_IO_Running: Yes                           <--- Slave IO 상태 Yes 여야함 
          Slave_SQL_Running: Yes                         <--- Slave SQL 상태 Yes 여야함
            Replicate_Do_DB:                                 <--- 전체 DB를 대상으로 하였기때문에 이하 공란
        Replicate_Ignore_DB:
         Replicate_Do_Table:
     Replicate_Ignore_Table:
    Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
                 Last_Errno: 0
                 Last_Error:
               Skip_Counter: 0
        Exec_Master_Log_Pos: 838408260
            Relay_Log_Space: 838408397
            Until_Condition: None
             Until_Log_File:
              Until_Log_Pos: 0
         Master_SSL_Allowed: No
         Master_SSL_CA_File:
         Master_SSL_CA_Path:
            Master_SSL_Cert:
          Master_SSL_Cipher:
             Master_SSL_Key:
      Seconds_Behind_Master: 0    < ----- 이 값이 크면 클수록 Master 로 부터 복제할수 없는 데이터가 많음을 의미?

 

간단한 제어

slave stop 을 하여 동기화를 중단하거나 중단하고 에러를 잡을때 쓰는듯함...

 
SLAVE STOP;
SLAVE START;
 
TIP) 교차적으로 자신의 Bin 로그와 상대편의 Relay 로그 가 일치해야 하며 상대편의 Bin 로그는 나의 Relay 로그와 일치

error)
 
Error running query, slave SQL thread aborted. Fix the problem, 
and restart the slave SQL thread with 'SLAVE START'. We stopped at log 
'mysql-bin.000001' position 19466
slave에서 master의 binlog을 읽어 들여 slave db에 업데이트를 하는 과정에서 
존재하는 테이블이거나 중복되는 값, 테이블 없는 등의 오류로 인해서 slave가 중지
되는 현상으로 아래와 같이 slave에서 해당 쿼리를 skip시켜 줌으로 해결 가능합니다.
 
mysql>stop slave;    --> slave 중지
 
mysql>set global sql_slave_skip_counter =3;  
- slave구동후에 마스터로 부터 읽어온 쿼리중에 취소해야할 쿼리 수 입력
 
mysql>start slave;   --> slave 시작
 
이미지 퍼옴 블로그 : http://vndfbfkd.tistory.com/575