Database Replication Architecture

DB Replication 구조

Source(원본) -- Replication(복제) 구조이다.

원본 서버에서 변경이 일어나면 복제 서버에도 동일하게 반영된다.

1. 원본 서버가 다운되면 복제 서버를 원본 서버로 승격시켜 사용할 수 있다.

2. 원본 서버를 Write DB로, 복제 서버를 Read DB로 사용해 부하를 분산시킬 수 있다.

MySQL 서버에서 발생하는 이벤트(삽입/삭제, 계정 권한 변경과 같은)가 발생하면 바이너리 로그에 기록된다.

• Binary Log : 이벤트(변경사항)이 로그파일에 순차적으로 기록된 것

원본 서버의 바이너리 로그를 복제 서버로 보내고, 복제 서버는 Relay Log라는 로컬 디스크에 저장하고 변경사항을 반영한다.

복제 토폴로지

1. 트랜잭션 스레드가 데이터를 처리하고 Binary log에 기록한다.

2. 바이너리 로그 덤프 스레드가 각 이벤트에 Lock을 설정하고 읽은 다음, 복제 서버로 전송한다.

3. Replicaiton I/O 스레드는 덤프 스레드가 보내준 이벤트를 자신의 로컬 파일인 Relay log에 저장한다.

• 아직 데이터는 반영되지 않은 상태이다. show replica status 명령으로 상태를 볼 수 있다.

1. Replication SQL 스레드가 Binary log를 DB에 반영한다. (I/O 스레드랑은 별개라고 한다.)

정리하면 이렇다.

Master(Source) 서버

• 레플리카 서버가 연결 될 때 바이너리 로그 덤프 스레드(Binary Log Dump Thread)를 생성해, 바이너리 로그 내용을 레플리카 서버로 전송한다.

Slave(Replica) 서버

• 레플리케이션(Replication) I/O 스레드를 생성해서 Master 서버의 바이너리 로그 덤프 스레드로부터 전달받은 이벤트를 가져와서 Relay log에 저장한다.

• 레플리케이션 I/O 스레드가 작성한 Relay log 파일의 이벤트를 레플리케이션(Replication) SQL 스레드가 읽고 실행(저장)한다.

식별 방법 (복제 방법)

레플리카 서버는 원본 서버의 이벤트에 대한 바이너리 로그를 어떻게 식별할까?

1. 바이너리 로그 파일 위치를 기반으로 하는 복제 (Binary Log File Position Based)

원본 서버의 바이너리 로그 파일명과 offset(position)을 가지고 식별한다.

그림에서는 offset 정보가 보이지만, 실제 파일에는 나타나지 않는다.

단점으로는 레플리카가 마스터로 승격되면 나머지 레플리카는 바뀐 마스터의 바이너리 오프셋을 다시 찾아야하기 때문에 복구에 시간이 걸리고, 중간에 네트워크 연결이 끊어지기라도 하면 변경 사항을 복제하지 못하는 경우도 발생할 수 있다.

2. 글로벌 트랜잭션 아이디 기반 복제 (Global Transaction ID = GTID)

MySQL 5.6부터는 GTID를 기본 복제방법으로 사용하고 있다.

• GTID = source_id:transaction_id로 구성되어 있다.

1. 마스터에서 각 트랜잭션에 고유한 GTID 할당

2. 마스터는 트랜잭션 로그와 함께 GTID를 바이너리 로그에 기록

3. 슬레이브는 바이너리 로그에서 트랜잭션과 GTID를 읽는다.

4. 슬레이브는 GTID를 사용해서 이미 적용된 트랜잭션은 무시하고 아직 적용되지 않은 트랜잭션에만 적용한다.

GTID_PURGED 값을 주의해서 관리해야 한다.

로그 파일에서는 offset 추적이 필요했지만, GTID는 동일한 값이기 때문에 트랜잭션 ID만 읽으면된다.

GTID 복제의 이점은 아래와 같다.

1. 자동 장애 조치 (Failover) 개선

• 장애 발생 시 다른 슬레이브를 새로운 마스터로 승격하는 과정이 더 간단하고 안정적

• GTID를 통해 각 트랜잭션의 실행 여부를 추적 가능

1. 복제 토폴로지 변경 용이성

• binary log 파일 위치를 수동으로 찾을 필요가 없음

1. 트랜잭션 일관성 보장

• 각 트랜잭션에 고유한 ID가 부여되기 때문에 중복 실행 방지 가능

• 누락된 트랜잭션 식별에 용이

바이너리 로그는 어떻게 저장될까? (Binary Log Format)

1. Row 방식 --> 변경된 데이터가 저장

매우 많은 데이터를 변경하는 경우 대량의 데이터가 로그에 기록되면서 과부하를 줄 수 있다.

1. Statement 방식 --> SQL문을 저장

실행한 SQL문을 그대로 바이너리 로그에 저장하는 형식이다. 단순 쿼리만 기록되기 때문에 적은 용량의 로그파일로 관리할 수 있다.

비확정 쿼리일 경우 데이터 동기화 문제가 발생할 수 있다. 따라서 트랜잭션 격리 수준이 Repeatable Read 이상만 가능하다.

• 비확정 쿼리 : 실행마다 다른 결과를 반환하는 SQL

• 마스터에서 timestamp를 실행하고 로그를 남겼는데, 슬레이브에서도 이를 적용하기 위해 timestamp를 실행한다면 두 실행 결과가 달라져 데이터 일관성의 문제가 있을 수 있다.

1. Mixed 방식 --> Statement + Row

평소에는 Statement 포맷으로 기록하다가 Statement 포맷으로 복제했을 때 문제가 될 가능성이 있는 쿼리는 Row 포맷으로 변환하여 기록해준다.

복제 동기화 방식

1. 복제 비동기 방식

mysql의 기본 복제 방식이다.

동기 방식에서는 덤프 스레드에서 작업이 시작되면 작업이 완료될 때까지 트랜잭션 스레드는 대기하게 된다. 또, 소스 서버가 복제 서버의 변경을 확인한다.

즉, 비동기 방식은 트랜잭션 스레드는 덤프 스레드의 작업 완료를 기다리지 않는것이다.

이처럼 동기 방식은 데이터의 일관성을 유지할 수 있겠지만, 비동기 방식은 마스터 서버에 장애가 발생하면 새롭게 추가된 데이터가 레플리카 서버에 반영되지 않아 데이터 정합성 문제가 발생할 수 있다.

• ex) 마스터 서버 장애 발생 전, 트랜잭션은 커밋 되었지만 바이너리 로그에 기록되지 않은 경우

2. 복제 반동기 방식

1. 트랜잭션 스레드가 커밋하게 되면 바이너리 로그에 변경 기록을 작성한다.

2. 덤프 스레드가 복제 서버 스레드에 릴레이 로그를 전송한다.

3. 복제 서버에서 변경된 데이터를 wrtie한다.

4. 복제 서버는 원본 서버에 write 했다는 응답을 보낸다.

5. 트랜잭션 스레드가 이를 확인하고 커밋을 확정하면서 원본 스토리지에 wirte 한다.

이런 과정이라면, 복제 서버에서 wrtie하고 중간에 트랜잭션이 rollback 된다면 복제 서버도 같이 rollback 되는것 같다.

Summary

레플리케이션은 부하 분산 및 백업 등을 위한 master/slave 구조로 구성하는 Scale-Out 솔루션이다.

클러스터링이라고도 하는 동기 복제 방식은 데이터 정합성을 보장하는 대신, 각 트랜잭션 내에서 다른 노드들과 동기화 하기 때문에 성능상 이슈가 있다. (클러스터링에는 논리적 복제 방식, 물리적 스토라지 공유 방식 등 다양한 방식이 존재)

레플리케이션 구조는 결국 트래픽에 대응하기 위함인데, 일반적으로 동기 복제 방식이 아닌 비동기 복제 방식이나 반동기(Semi-Sync) 복제 방식을 사용한다고 한다. 대부분 요청이 read 작업인 특징이면 master 노드는 write 작업으로, 복제(slave)노드들은 read 작업으로 라우팅하여 부하를 분산한다.