Replication Type (복제 타입)

MySQL의 복제는 2가지 타입으로 나뉘고, 각 방식의 동작 원리와 구축 방법을 알아보겠습니다.

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

• Source Server의 Binaray Log에 기록된 변경 내역(바이너리 로그 이벤트)들을 식별하는 방식

1. 글로벌 트랜잭션 ID 기반 복제(Global Transaction Identifiers Based Replication)

• 각 트랜잭션에 고유한 식별자(ID)를 부여하여 추적하는 방식입니다.

Binary Log File Position Based

이 방식은 복제 기능이 처음 도입됐을 때부터 제공된 방식으로, 레플리카 서버에서 소스 서버의 바이너리 로그 파일명과 파일 내에서의 위치(Offest or Postion)로 바이너리 로그 이벤트를 식별해서 복제가 진행되는 형태입니다.

복제를 처음 구축할 때 레플리카 서버에 소스 서버의 어떤 이벤트부터 동기화를 수행할 것인가에 대한 정보를 설정합니다.

• 복제가 설정된 레플리카 서버는 소스 서버의 어느 이벤트까지 로컬 디스크로 가져왔고, 적용했는지에 대한 정보를 관리

• 위 정보를 소스 서버에 전달해서 이후의 바이너리 로그 이벤트들을 가져옵니다.

이러한 이유로 소스 서버에서 발생한 각 이벤트에 대한 식별이 반드시 필요합니다.

1. 핵심 동작 원리: 파일 이름과 위치(Offset)

소스 서버의 바이너리 로그에 기록된 변경 내역들은 물리적인 파일 위치로 식별하는 방식입니다.

레플리카 서버는 소스 서버에게 "소스 서버야, mysql-bin.0001 파일의 4820번 위치부터 변경된 내용을 보여줘." 라고 요청하며 동기화를 진행합니다.

레플리카 서버는 이처럼 각 이벤트들을 식별하고 자신의 적용 내역을 추적함으로써 복제를 일시적으로 중단할 수 있으며, 재개할 때도 자신이 마지막으로 적용했던 이벤트 이후의 이벤트들부터 다시 읽어올 수 있습니다.

즉, 복제 과정에서 가장 중요한 정보는 로그 파일명(File Name)과 파일 내 위치(File Offset)의 조합입니다.

2. 복제 프로세스

1. 동기화 지점 설정:

• 복제를 처음 구축할 때, 레플리카 서버는 소스 서버의 "어느 파일, 어느 위치"부터 데이터를 가져올지 설정합니다.

1. 이벤트 수신 및 기록:

• 레플리카 서버는 소스 서버로부터 이벤트를 받아와 로컬 디스크(릴레이 로그)에 저장하고 이를 적용합니다.

1. 위치 관리:

• 레플리카 서버는 자신이 소스 서버의 이벤트를 어디까지 가져왔고, 어디까지 적용했는지를 지속적으로 관리합니다.

이러한 복제 프로세스 덕분에 복제를 일시적으로 중단했다가 재개하더라도, 레플리카 서버는 기억해 둔 마지막 위치(Offset) 이후의 이벤트부터 다시 요청하여 누락 없이 데이터를 동기화할 수 있습니다.

3. 필수 주의 사항: 고유한 server_id

바이너리 로그 기반 복제에서 가장 중요한 설정은 server_id입니다.

복제 토폴로지에 참여하는 모든 MySQL 서버는 반드시 서로 다른 고유한 server_id를 가져야 합니다.

• 기본값: 1 (설정하지 않으면 충돌 발생)

• 레플리카 서버에 설정된 값과 동일한 경우 레플리카 서버에서는 해당 이벤트를 적용하지 않고 무시하게 됩니다.

GTID Based Replication

MySQL 5.6 버전부터 도입된 GTID(Global Transaction Identifier) 방식은 물리적인 파일 위치가 아닌, 논리적인 트랜잭션 ID를 기반으로 복제를 수행합니다.

1. GTID란?

GTID는 소스 서버에서 커밋된 각 트랜잭션에 부여된 전역적으로 고유한 식별자입니다.

$$GTID = source\_uuid : transaction\_id$$

• source_uuid: 트랜잭션이 최초로 발생한 서버의 고유 식별자

• transaction_id: 해당 서버에서 트랜잭션이 발생한 순서(일련번호)

예를 들어 3E11FA47...:23이라는 GTID는 특정 서버에서 23번째로 발생한 트랜잭션임을 의미합니다. 이 ID는 전체 복제 그룹 내에서 유일합니다.

2. 핵심 동작 원리: 자동 포지셔닝 (Auto-Positioning)

파일 위치 기반 복제가 "좌표(파일명+위치)"를 일일이 맞췄다면, GTID 복제는 집합(Set) 개념을 사용합니다.

1. 레플리카 서버는 소스 서버에 연결할 때, "나는 지금까지 이러한 GTID 집합을 처리했어"라고 자신의 상태를 보냅니다.

2. 소스 서버는 자신이 가진 트랜잭션 중 레플리카에 없는 트랜잭션만 자동으로 선별하여 보내줍니다.

관리자가 로그 파일명이나 위치를 직접 계산하거나 입력할 필요가 없으므로 운영이 훨씬 편리해집니다.

3. 장점

• 간편한 장애 조치(Failover):

  • 소스 서버가 다운되어 새로운 소스 서버를 선출해야 할 때, GTID 방식은 서버 간 동기화 지점을 자동으로 계산해주므로 복구 절차가 매우 간단합니다. (파일 기반 복제는 이 과정이 복잡하고 수동 계산이 필요할 수 있습니다.)

• 데이터 일관성:

  • 트랜잭션 단위로 식별하므로 데이터 누락이나 중복 적용을 더 확실하게 방지할 수 있습니다.