MySQL Slave의 Replication 복제 지연 속도 개선팁

 

 

MySQL의 Slave Lag(복제 지연) 문제와 Replication 동기화 성능 개선에 대한 내용을 정리해볼게요.

🕰 MySQL Slave Lag (복제 지연)

MySQL의 레플리케이션(replication) 환경에서 Slave가 Master로부터 변경 사항을 받아 적용하는 과정에서 지연(lag)이 발생할 수 있어요. 주요 원인은 다음과 같습니다:

1. 네트워크 지연
   • Master와 Slave 간의 데이터 전송 속도가 느려서 발생하는 문제
   • 특히 WAN 환경에서는 네트워크 레이턴시가 높아지면 복제 지연이 심화
2. 쿼리 실행 속도 차이
   • Master에서 실행된 쿼리가 Slave에서도 동일하게 실행되는데, Slave의 성능이 낮으면 적용 속도가 느려지며 지연 발생
   • 복잡한 UPDATE나 DELETE 문이 많을 경우 Slave의 부하 증가
3. IO 및 Disk 성능
   • Slave가 binlog를 읽고 데이터를 디스크에 저장하는 과정에서 디스크 I/O 병목이 발생하면 지연 증가
   • SSD보다 HDD를 사용하는 환경에서는 IOPS가 낮아 지연이 심해질 수 있음
4. Single-Threaded Replication
   • 기본적으로 MySQL의 복제는 단일 스레드(single-threaded)로 적용되며, 다수의 트랜잭션이 병렬 처리되지 못함
   • 이로 인해 Master의 다중 트랜잭션을 처리하는 속도보다 Slave의 적용 속도가 뒤처질 수 있음

 

 

 

 

---

🚀 Replication 복제 지연 개선 방법

복제 성능을 개선하는 방법을 몇 가지 정리해볼게요.

1. Parallel Replication 활성화
   • MySQL 5.6부터 멀티 스레드 슬레이브(MTS, Multi-Threaded Slave) 기능이 추가되어 다중 트랜잭션을 병렬로 실행 가능
   • slave_parallel_workers 값을 늘려 병렬 처리를 최적화
2. Replication 방식 변경
   • 기본적인 비동기식 복제(Asynchronous Replication)는 Master가 트랜잭션을 실행 후 즉시 완료 처리
   • 반면 반동기식 복제(Semi-Synchronous Replication)는 최소한 한 개의 Slave가 적용 완료할 때까지 기다려서 지연을 줄일 수 있음
3. Binlog 설정 최적화
   • sync_binlog=1 설정을 활용하면 장애 발생 시 데이터 무결성을 보장하지만 I/O 비용 증가
   • sync_binlog=0으로 설정하면 성능이 향상되지만 장애 발생 시 일부 데이터가 손실될 가능성이 있음
4. Hardware 업그레이드
   • SSD를 활용하여 디스크 I/O 병목을 해결
   • Slave 서버의 CPU 및 메모리 리소스를 충분히 확보하여 쿼리 실행 속도를 개선
5. 쿼리 최적화
   • 복잡한 UPDATE 또는 DELETE 문을 작은 batch 단위로 처리하여 Slave 부하 감소
   • 인덱스를 적절하게 설정하여 SELECT 문 성능 개선
6. 동기화 처리 속도 개선  
   
   • binlog_group_commit_sync_delay  를 이용하여 Bulk Data 병렬 처리 향상하거나
   • 여러개의 Thread를 이용하여 병렬 처리가 가능
   • slave_parallel_threads=2
     slave_parallel_workers=2

 

 

🔍 복제 지연 개선 팁 정리!

✅ Slave Lag는 네트워크, 쿼리 복잡도, 디스크 I/O 문제 등으로 인해 발생원인 파악
✅ Parallel Replication, Replication 방식 변경, Hardware 업그레이드 등의 방법으로 개선 가능
✅ 쿼리 최적화 및 binlog 설정 파라미터를 활용하면 Slave의 동기화 성능을 더욱 향상 가능

 

 

---

MySQL의 복제 성능과 안정성을 극대화할 bin-log 설정 파라미터

 

 

MySQL의 Binlog 관련 주요 파라미터를 정리해볼게요. 이 설정들은 복제 성능, 데이터 무결성, 저장 공간 등을 최적화하는 데 중요한 역할을 합니다.

🛠 Binlog 관련 주요 파라미터

파라미터	설명	추천 설정
log_bin	Binary Log 활성화 여부	ON (복제 및 PITR를 위해 필수)
binlog_format	Binlog 기록 방식 (SBR, RBR, MBR)	MIXED,ROW(정확한 복제 보장)
binlog_cache_size	트랜잭션 중 임시로 binlog를 저장하는 버퍼 크기	1MB 이상 (트랜잭션이 많다면 증가)
sync_binlog	Binlog를 디스크에 동기화하는 방식	1 (데이터 무결성 보장), 0 (성능 우선)
expire_logs_days	Binlog 유지 기간 (일 단위)	7~30일 (보관 기간에 따라 설정)
max_binlog_size	단일 binlog 파일의 최대 크기	256MB~1GB (환경에 따라 조정)
binlog_row_image	Row-Based Logging에서 저장되는 데이터의 범위	FULL (복제 정확도 보장), MINIMAL (공간 절약 가능)
binlog_checksum	Binlog 체크섬 사용 여부	CRC32 (데이터 무결성 검증)
binlog_gtid_simple_recovery	GTID 복구 성능 최적화	ON (GTID 사용 시 성능 향상)
binlog_group_commit_sync_delay	Group Commit의 fsync 지연 시간 (마이크로초)	0~1000 (트랜잭션 병렬 처리 최적화)
slave_parallel_threads=N	Slave bin 로그를 처리하는 Thread 관리	slave_parallel_threads=2
slave_parallel_workers=N	Slave bin 로그를 처리하는 작업량 관리	slave_parallel_workers=2

 

 

🚀 설정 최적화 팁

✅ 복제 환경에서는 binlog_format=ROW를 설정하여 정확한 복제를 보장하세요.
✅ 데이터 무결성이 중요한 경우 sync_binlog=1을 사용해 장애 발생 시 데이터 손실을 방지하세요.
✅ 복제 성능 최적화를 위해 binlog_group_commit_sync_delay를 활용해 트랜잭션을 효율적으로 묶어서 저장하세요.
✅ 스토리지 부담을 줄이려면 expire_logs_days를 적절히 조정해 불필요한 binlog 파일을 자동 삭제하도록 설정하세요.

 

 

 

[관련자료]

 

https://www.abelworld.com/mysql-slave-master-switch/

https://deepakmysqldba.wordpress.com/2021/05/20/446/

https://medium.com/codex/an-overview-of-mysql-replication-9e5635cc3a8a

https://dev.mysql.com/blog-archive/mysql-group-replication-hello-world/