인사이트리포트

들어가며

MariaDB Replication(복제)은 데이터베이스의 확장성과 고가용성, 장애 복구를 위한 핵심적인 기능이다. 올바른 복제 구조 설계와 성능 관리, 그리고 철저한 모니터링은 데이터 일관성 보장과 시스템 안정성 유지에 있어 필수적이다. 특히, 고부하 트랜잭션 처리 환경에서 복제 지연, 슬레이브 동기화 문제, 네트워크 병목 등 다양한 이슈는 성능 저하로 이어질 수 있다.

본 리포트에서는 MariaDB Replication 구조와 주요 활용 사례, Replication 환경의 성능 관리와 모니터링 전략, 주요 진단 지표와 Replication 성능 개선을 위한 방안에 대해 상세히 다룬다. 성능 테스트를 통한 Replication 지연, Slave 동기화 상태, 바이너리 로그와 GTID, Thread 모니터링 등 Replication의 핵심 요소를 효과적으로 진단하고 조정하는 방안을 알아보자.

MariaDB Replication 구조

MariaDB Repliaction은 하나 이상의 서버(Primary, Master)의 데이터를 하나 이상의 다른 서버(Replica, Slave)에 동기화 하는 기능이다. Replication의 주요 메커니즘은 바이너리 로그를 기반으로 동작한다. Binlog Dump Thread는 Master에서 데이터 변경 작업(INSERT, UPDATE, DELETE)이 발생하면 기록된 바이너리 로그의 이벤트 Slave의 I/O Thread에 전달한다. 이후 Slave I/O thread가 Relay log에 저장 후, SQL thread가 직접 Slave에 적용한다. Slave는 어떤 위치까지 바이너리 로그를 적용했는지 추적하여, 일시적인 네트워크 장애나 복제 중단 후에도 중단된 지점부터 복제를 재개할 수 있다. Master와 Slave는 항상 연결되어 있을 필요 없이, 복제 중단/재개가 가능하다.

[ 각 Thread 별 역할 ]

MariaDB Replication 주요 활용 사례

1.  읽기 부하 분산

하나 이상의 Slave를 두어 읽기 작업을 여러 서버에 분산시키면, Master 서버의 부하를 줄일 수 있다. 읽기 작업이 많고 쓰기 작업은 적은 환경에서 가장 흔한 시나리오는 모든 쓰기 작업이 발생하는 하나의 Master 서버가 있고, 여러 Slave가 대부분의 읽기 작업을 처리하여 전체적인 시스템 부하를 분산시킬 수 있다.

2. 고가용성 및 장애 복구

Slave은 Master 서버의 실시간 백업 역할을 수행한다. Master 서버에 장애가 발생하더라도 복제 지연이 최소화된 Slave 서버를 즉시 새로운 Master로 승격시켜 시스템 중단 시간을 최소화하고 안정성을 높일 수 있다.

3. 데이터 백업 및 재해 복구(DR)

Slave 서버는 Master의 모든 변경 사항을 즉시 반영하여 항상 최신 상태의 데이터 복사본을 유지할 수 있다. 복사본을 활용하면 운영 중인 Master 서버에 부하를 주지 않고, Slave 서버에서 안정적으로 백업을 수행할 수 있다. 또한 Slave 서버를 지리적으로 분리된 원격지에 배치하면 심각한 재해로 Master 서버가 완전히 손실되더라도 원격의 Slave를 새로운 Master로 승격시켜 재난으로부터 대비할 수 있다.

MariaDB Replication 버전 호환성

MariaDB Replication 구성에서 업그레이드 시 Master와 Slave 간 버전 차이로 인한 데이터 불일치 및 복제 중단 위험을 방지하기 위해 버전 간 호환성을 확인해야 한다.

다음 표는 MariaDB 서버 버전 간 복제 호환성을 나타낸 표이다.

복제 환경의 안정성을 위해 Master와 Slave 간 MariaDB 버전이 동일한 것을 권장하며, 시스템 중단이 어려운 경우, 모든 Slave를 먼저 업그레이드하고 Master 서버를 업그레이드 하는 방법을 통해 시스템 중단을 최소화 할 수 있다. 이 방식은 Minor Upgrade에도 적용 가능하다.

MariaDB Replication 모니터링 방안

1. Thread 모니터링

SHOW PROCESSLIST 명령어를 통해 Replication과 관련된 Master와 Slave의 각 Thread를 모니터링 할 수 있다.

[ Master ]

[ Master ]

여기서 Thread ID 5는 연결된 Slave를 서비스하는 Binlog Dump Thread 이다. State는 대기 중인 모든 업데이트가 Slave 서버로 전송되었으며, 현재 Master 서버가 새로운 업데이트가 발생하기를 기다리고 있음을 나타낸다. 만약 Master 서버에서 Binlog Dump Thread가 없다면, 이는 연결된 Slave가 없음을 의미하고 복제는 동작하지 않는다.

[ Slave ]

Thread ID 8 은 Master 서버와 통신하는 I/O Thread이며, Thread ID 9 는 Relay Log에 기록된 이벤트를 읽어서 Worker Thread에 할당하는 SQL Thread이다. Thread ID 10,11 은 SQL Thread로부터 트랜잭션 작업을 할당 받아 Slave 서버에 변경 사항을 병렬로 적용함으로써 복제 속도를 높이는 Worker Thread이다. Worker Thread는 병렬 설정을 하였을 경우에만 나타난다. SHOW PROCESSLIST를 통해서, 각 Thread들의 State 지표를 통해 현재 수행 상태를 모니터링 할 수 있다. 각 Thread별 발생할 수 있는 State 지표는 다음과 같다.

[ Slave Thread 별 주요 상태 지표 ]

2. Slave 상태 모니터링

SHOW SLAVE STATUS는 Slave 서버의 복제 상태 및 진행 상황에 대한 상세 정보를 제공한다.

Replication이 지연 되는 것을 확인 할 수 있는 지표는 ‘Seconds_Behind_Master’와 ‘Slave_SQL_Running_State’이다. Seconds_Behind_Master는 Master 서버의 데이터가 Slave에 얼마나 늦게 반영되고 있는 지를 초(second) 단위로 나타내는 값이다. 이 값이 증가하면 Replication 지연이 발생하고 있는 것이다. Slave_SQL_Running_State는 SQL Thread가 현재 어떤 작업을 수행하고 있는지 보여주는 상태 정보이다.

Slave_IO_Running: Yes 이고 Slave_SQL_Running: No 인 상태라면, Last_SQL_Error 필드를 확인하여 SQL Thread가 멈춘 정확한 오류 메시지를 확인 할 수 있다. 이 상태는 I/O Thread가 데이터를 계속 가져오기 때문에 Relay Log에 적용되지 않은 이벤트가 계속 쌓여서 Replication 지연이 발생하는 상황을 만든다.

반대로 Slave_IO_Running: No 이고 Slave_SQL_Running: Yes 인 상태라면, Last_IO_Error 필드를 확인하여 I/O Thread가 멈춘 정확한 오류 메시지를 확인 할 수 있다.

 [ Slave 상태 주요 지표 ]

3. 바이너리 로그 모니터링

로그 디렉토리에는 서버가 생성한 여러 바이너리 로그들의 파일명을 순서대로 기록한 인덱스 파일로 복제 및 복구에 사용되는 Index 파일이 있다. Master에서는 mysql-bin.index, Slave는 relaylog.index 파일이 존재하며, my.cnf에 파일명을 지정하여 변경이 가능하다. 이 파일을 통해 Master에서 어떤 로그들을 작성하고 있는지 확인이 되고 Slave에서는 어떤 Relay 로그가 현재 서버에 적용 중인지를 확인할 수 있다.

Parallel Replication을 통한 성능 개선

예전의 MariaDB Replication은 Master에서 단일 SQL Thread로 바이너리 로그를 읽어 Slave에 반영하는 Single-Threaded Replication 방식이었다. 이 방식은 Master의 부하가 크고, 특히 쓰기 작업이 많은 경우 Slave의 반영 속도가 Master를 따라가지 못해 Replication Lag 현상이 종종 발생했다.

Parallel Replication은 이러한 한계를 극복하기 위해 등장했다. Master에서 실행된 트랜잭션들을 Slave에서 여러 개의 Worker Thread가 병렬로 처리하여 Replication Lag을 최소화하고 성능을 크게 개선할 수 있다. Parallel Replication을 사용하기 위한 설정에 대해 알아보자.

[ Parallel Replication 관련 변수 ]

Parallel Replication 설정에 따른 성능 비교

Parallel Replication 설정에 따라 Replication 성능이 어떻게 달라지는지 아래 테스트를 통해 알아보자.

테스트 구성

1. 병렬도(slave_parallel_thread)에 따른 성능 테스트

Worker Thread가 많아질수록 Seconds_Behind_Master 값이 적게 발생됨을 알 수 있으며, 이는 복제 처리 속도가 빠름을 알 수 있다.

2. 병렬 모드(slave_parallel_mode)에 따른 성능 테스트

slave_parallel_mode를 Conservative Mode로 설정 할 경우, Optimistic Mode로 설정했을 경우보다 Seconds_Behind_Master 값이 적게 발생되고 복제 처리 속도가 더 빠름을 알 수 있다. Read/Write 경합이 높은 경우, Conservative Mode는 Master의 그룹 커밋을 활용하여 충돌 가능성을 줄여 병렬 복제를 수행한다. Optimistic Mode는 더 많은 병렬화를 시도하지만, 충돌 시 재시도 오버헤드가 발생하여 복제 성능이 저하 될 수 있다. 따라서 충돌 빈도가 높은 OLTP 환경에서는 Conservative Mode가 더 예측 가능하고 안정적인 복제 성능을 제공 할 수 있다.

마치며

본 리포트를 통해 MariaDB Replication의 구조적 이해와 함께 성능 관리 및 모니터링의 중요성을 다시 한 번 짚어보았다. 복제 환경에서 발생할 수 있는 다양한 지연 및 동기화 문제는 시스템 전체의 안정성과 효율성에 직접적인 영향을 미치기 때문에, 체계적인 모니터링과 신속한 대응 체계 구축이 필수적이다.

본 리포트에서 제시한 모니터링 전략과 성능 최적화 방안이 효율적인 복제 운영에 도움이 되길 바란다.