일반 모드에서 복제 실패 시 장애 처리

SLAVE 에서 실행. Master 변경 사항이 Slave 로 복제되는 시간을 지연시킴

STOP SLAVE;
CHANGE MASTER TO master_delay=300;
START SLAVE;
show slave status\G;

실행 명령어

k exec -it mariadb-1 -- mariadb -uroot -psecret -e "STOP SLAVE;CHANGE MASTER TO master_delay=3600;START SLAVE;show slave status\G;";

k exec -it mariadb-2 -- mariadb -uroot -psecret -e "STOP SLAVE;CHANGE MASTER TO master_delay=3600;START SLAVE;show slave status\G;";

k exec -it mariadb-0 -- mariadb -uroot -psecret -e "USE mysql;CREATE OR REPLACE TEMPORARY TABLE TEMP(DATA VARCHAR(100))";

트랜잭션 생성, Master 의 GTIP가 하나 증가되었음을 확인

Master는 종료하고 Slave의 delay 를 0으로 주어 master 변경 유도

k exec -it mariadb-1 -- mariadb -uroot -psecret -e "STOP SLAVE;CHANGE MASTER TO master_delay=0;START SLAVE;show slave status\G;";

k exec -it mariadb-2 -- mariadb -uroot -psecret -e "STOP SLAVE;CHANGE MASTER TO master_delay=0;START SLAVE;show slave status\G;";

STOP SLAVE;
CHANGE MASTER TO master_delay=0;
START SLAVE;
show slave status\G;

vagrant@slave3:~$ k get po
NAME READY STATUS RESTARTS AGE
mariadb-0 1/1 Running 0 21m
mariadb-1 1/1 Running 1 (81m ago) 24h
mariadb-2 1/1 Running 11 (84m ago) 6d
maxscale1-67549f6886-nvgnz 1/1 Running 12 (85m ago) 6d2h

Master가 삭제 하여 Slave 가 Master가 승격되드록 유도. delay time이 풀어져야 Slave 의 Master승격이 가능하므로 Slave의 delay time을 0으로 바꾸는 명령을 뒤이어 바로 수행한다.
k delete po mariadb-0

k exec -it mariadb-1 -- mariadb -uroot -psecret -e "STOP SLAVE;CHANGE MASTER TO master_delay=0;START SLAVE;show slave status\G;";

k exec -it mariadb-2 -- mariadb -uroot -psecret -e "STOP SLAVE;CHANGE MASTER TO master_delay=0;START SLAVE;show slave status\G;";

아래처럼 Master가 바뀐것을 확인하면 mariadb-0 삭제 명령 수행을 그만하고 재시작되기를 기다린다.

Master 가 Slave보다 트랜잭션 수가 적은 데이터 동기화 실패의 결과가 나왔다. 이 경우는 데이터를 수작업으로 정리해 주어야 한다.

MaxScale의 Reset Replication 기능으로 아래처럼 GTID 초기화가 가능하나 데이터는 여전히 정리되지 않은 상태이다.

SEMI SYNC 모드에서 복제 실패 시 장애 처리

server1을 Master로 변경

Sync Mode 설정

Master와 Slave 각기 global rpl_semi_sync_master_enabled, rpl_semi_sync_slave_enabled 변수를 활성화한다.

k exec -it mariadb-0 -- mariadb -uroot -psecret -e "set global rpl_semi_sync_master_enabled = ON;show variables like '%rpl%';";

k exec -it mariadb-1 -- mariadb -uroot -psecret -e "stop slave;set global rpl_semi_sync_slave_enabled = ON;start slave;show variables like '%rpl%';";

k exec -it mariadb-2 -- mariadb -uroot -psecret -e "stop slave;set global rpl_semi_sync_slave_enabled =ON;start slave;show variables like '%rpl%';";

변수 값은 세션이 끊기면 사라지므로 서버 설정에 추가하는 것이 좋다. 컨피그맵에 rpl_semi_sync_master_enabled=1,rpl_semi_sync_slave_enabled=1를 추가하고 apply 한다. mariadb를 rollout 한다.

apiVersion: v1
kind: ConfigMap
metadata:
  name: mariadb
data:

  primary.cnf: |
    [mariadb]
    log-bin
    log-basename=mariadb
    log_slave_updates
    rpl_semi_sync_master_enabled=1
  replica.cnf: |
    [mariadb]
    log-bin
    log-basename=mariadb
    log_slave_updates
    rpl_semi_sync_slave_enabled=1
  primary.sql: |
    CREATE USER 'repl'@'%' IDENTIFIED BY 'secret';
    GRANT ALL PRIVILEGES ON *.* TO 'repl'@'%';
  secondary.sql: |
    CHANGE MASTER TO
    MASTER_HOST='mariadb-0.mariadb.default.svc.cluster.local',
    MASTER_USER='repl',
    MASTER_PASSWORD='secret',
    MASTER_CONNECT_RETRY=10;

k apply -f cm.yml
k rollout restart sts mariadb 

지연 시간 설정

Master , Slave 간 지연 시간을 두어 Master 장애 시 Slave로 복제하지 못한 경우를 만들어 본다.

k exec -it mariadb-1 -- mariadb -uroot -psecret -e "STOP SLAVE;CHANGE MASTER TO master_delay=3600;START SLAVE;show slave status\G;";

k exec -it mariadb-2 -- mariadb -uroot -psecret -e "STOP SLAVE;CHANGE MASTER TO master_delay=3600;START SLAVE;show slave status\G;";

Master 트랜잭션 생성

Master에 트랜잭션을 일으켜 Master와 Slave의 GTID가 차이나게 한다. 지연시간으로 인해 동기화 하지 못하는 상황이다.

k exec -it mariadb-0 -- mariadb -uroot -psecret -e "create database test;";

Master 장애 유발

Master POD를 삭제하여 장애를 일으킨다. 지연시간을 없애어 Slave 의 Master승격이 될 수 있도록 한다. POD가 금새 정상화될 수 있으므로 Master 변경 전까지 삭제 커맨드를 계속 날려준다.
k delete po mariadb-0

k exec -it mariadb-1 -- mariadb -uroot -psecret -e "STOP SLAVE;CHANGE MASTER TO master_delay=0;START SLAVE;show slave status\G;";

k exec -it mariadb-2 -- mariadb -uroot -psecret -e "STOP SLAVE;CHANGE MASTER TO master_delay=0;START SLAVE;show slave status\G;";

POC 결론

일반적인 환경에서 Master 커밋 후 Slave 로 데이터가 복제되기 전 Master 장애 시에는 데이터 불일치 문제가 해소되지 않았다. Master의 트랜잭션 정보는 binlog에는 존재하나 Slave의 Relay Log로 전달되지 않았으므로 기존 Master가 복구되면 Slave상태로 복구되나 Master보다 데이터를 많이 가지게 된다. Semi Sync 모드로 진행할 경우 Master 커밋 후 장애가 나고 Slave가 Master가 승격된 후에 기존 Master가 Slave로 복구된 후에 추가되었던 데이터의 동기화가 이루어진다.