MySQL Master Slave 복제 지연 해결 방안 | 예방 방안
발생 상황
MySQL 5.xx버전 Master - Slave로 서버를 구성해놓은 상황에서, Master 서버에 대량 delete 작업을 수행했다.
binlog에 많은 로그 데이터가 쌓였다. 총 테이블의 사이즈가 0.2GB 정도여서 Slave 서버에서 지연은 발생하지 않을 것으로 예상했다. 데이터를 약 10만건씩 삭제 하던 중 Slave에서 정상적으로 복제가 되지 않는 것을 알게되었다. 정상적으로 안된다기 보다 복제가 지연되는것을 발견했다.
show slave status; 를 했을때 아래 두 항목에 대해서는 정상적으로 복제 스레드가 진행되고 있었지만, Seconds_Behind_Master가 쌓이기 시작했다.
- Slave_IO_Running: Yes (정상)
- Slave_SQL_Running: Yes (정상)
- Seconds_Behind_Master : 0이 아닐경우 해당 초만큼 복제가 지연되고 있다는 의미이다.
추후 동일 이슈가 발생할 상황을 대비해 해결방안을 정리해놓기로 했다.
※ 물론 이 경우 replication이 깨진 것은 아니기 때문에 시간이 해결해 주긴 할거다.. (언젠간 복제가 완료될 것이라는 의미) 하지만 Slave가 서비스용 서버일 경우 실시간 동기화가 가능해야하기 때문에 조치가 필요하다.
해결 방안
[ 백업을 사용한 Slave 재설정 ]
만약 복제가 몇시간씩 지연된다면... 차라리 slave 쪽 서비스를 잠깐 막고 slave 서버를 다시 구성하는게 빠를 수 있다.
- Master의 최신 데이터를 백업 (mysqldump 또는 xtrabackup 사용).
- Slave에서 기존 데이터를 삭제하고 새 데이터를 복원.
CHANGE MASTER TO MASTER_HOST='master_host',
MASTER_USER='replication_user',
MASTER_PASSWORD='replication_password',
MASTER_LOG_FILE='master-bin.000001',
MASTER_LOG_POS=12345;
START SLAVE;[ Slave SQL Thread 속도 향상 ]
!! 이 방법들은 데이터 일관성이 깨질 가능성이 있다 !!
디스크 동기화 최소화
- sync_relay_log와 sync_relay_log_info 값을 0으로 설정해 디스크 동기화를 줄인다.
SET GLOBAL sync_relay_log = 0;
SET GLOBAL sync_relay_log_info = 0;Slave 서버의 성능 최적화
- Slave 서버의 디스크, CPU, 메모리 사용량을 점검하고, 부족한 자원을 늘린다.
- innodb_flush_log_at_trx_commit을 임시로 2로 변경하여 I/O 병목을 줄인다.
SET GLOBAL innodb_flush_log_at_trx_commit = 2;Replication Parallelism 활성화
- 이런 방법이 있긴 하지만... 운영 중 어떤 side effect가 있을지 모르기에 나라면 사용 안 할 것 같다...
- 그것도.. global variables 를...
SET GLOBAL slave_parallel_workers = 4; -- 적절한 값으로 설정
예방 방안
사실 위 방법 다 필요없고.. 처음부터 작업 대상 단위를 5000건 정도씩 쪼개서 batch 로 매일 조금씩 지우는게 가장 효율적이다. 실제로 대량 삭제 작업을 새벽에 돌렸었는데 새벽에는 리소스를 사용하는데가 거의 없지만 그때도 master 와 slave와 중간중간 세션이 끊기는 문제가 몇번 발생한 경험이 있었다. 무조건 트랜잭션 단위를 limit으로 끊어서 조금씩 자주 삭제하는걸로 하자.