MySQL Crash-safe replication

MySQL crash-safe replication

MySQL crash-safe replication 기능은 5.6 버전부터 생긴 오래된 개념입니다.
slave DB가 crash 되어 재기동 되는 경우에도 data 중복이나 유실 같은
replication이 깨지는 경우를 막기 위한 기능인데요
이번 글에서는 MySQL crash-safe replication 에 대해서 살펴보겠습니다.

crash-safe replication 개념

replication 수행 중 Slave의 status를 file에 update 하기 전에 Slave DB가 crash 후 재기동 되는 경우 마지막 트랜잭션을 재수행 하기 때문에 중복 에러등으로 replication이 깨질 수 있습니다.

이를 보완하기 위해 나온 설정이 relay_log_info_repository=TABLE 이며
트랜잭션 안에 replication 정보를 포함시켜 data 반영 SQL과 replication status update가 한 트랜잭션으로 묶여
이 두가지가 모두 성공해야만 DB에 반영하도록 하는 설정입니다.

begin;
insert into tb_test values(1);
update mysql.slave_relay_log_info set Relay_log_name='./relay-bin.000006',replay_log_pos=1356;
commit;

추가로 필요한 relay_log_recovery 설정은 Slave DB 재기동 후 replication 설정을 불러올 때
master info가 아닌 relay_log 정보만을 갖고 복구를 수행하도록 하는 설정 입니다.

2020-05-03T12:19:21.402872Z 0 [Warning] [MY-010539] [Repl] Recovery from master pos 1142 and file mysql-bin.000003 for channel ''. Previous relay log pos and relay log file had been set to 322, ./relay-bin.000014 respectively.

정리하면 relay_log_info_repository=TABLE 과 relay_log_recovery 설정을 통해
Slave가 Crash 난 후 재기동 시 발생할 수 있는 문제점들을 해결할 수 있습니다.

crash-safe replication process

위에서 살펴본 crash-safe replication은 아래와 같은 흐름으로 동작합니다.
녹색 표시가 crash-safe replication에 직접 관여되는 부분입니다.

• 필수 설정

relay_log_info_repository = TABLE
relay_log_recovery = ON

• replication process

1. I/O thread는 Master의 binlog data를 slave의 relay log 로 저장
2. I/O thread는 가져온 Master의 binlog 정보를 mysql.slave_master_info에 update
3. SQL thread는 relay log를 읽어 transaction을 slave DB에 반영함
4. SQL thread가 반영한 relay log 정보를 slave_relay_log_info에 업데이트함