MySQL Replication

하나의 MySQL 데이터베이스 서버(main)의 데이터를 하나 이상의 MySQL 데이터베이스 서버(replica)에 복사할 수 있도록 하는 프로세스입니다.

Purpose

• 중복성 및 고가용성
  • DB 복제는 데이터의 여러 복사본을 유지하여 중복성을 제공합니다. 메인 서버에 오류가 발생하는 경우 레플리카 서버 중 하나가 메인 서버의 역할을 하도록 승격되어 데이터베이스의 고가용성을 보장할 수 있습니다.
• 로드 밸런싱
  • DB 복제를 사용하면 여러 서버에 읽기 작업을 분산시켜 데이터베이스의 로드 밸런싱을 수행할 수 있습니다. 레플리카 서버는 읽기 쿼리를 처리하여 메인 서버의 읽기 관련 처리 부하를 완화할 수 있습니다.
• 지리적 배포
  • 복제를 통해 다양한 지리적 위치에 데이터베이스 복사본을 쉽게 만들 수 있습니다. 이를 통해 기본 데이터 센터에서 멀리 떨어진 사용자의 성능을 향상할 수 있으며 재해 복구 기능도 제공할 수 있습니다.

 

Replication Process

• 메인-레플리카 관계
  • MySQL 복제에는 메인-레플리카 관계가 있습니다. 메인은 데이터베이스에 대한 모든 변경이 이루어지는 기본 서버이고, 레플리카는 메인에서의 변경 사항을 복제하는 서버입니다.
• 바이너리 로깅
  • 바이너리 로깅은 데이터베이스에 대한 모든 변경 사항을 바이너리 로그 파일에 기록하는 MySQL의 기능입니다.
  • 메인 서버에서 데이터베이스에 대한 모든 변경 사항은 바이너리 로그에 기록됩니다.
  • 이 로그에는 모든 데이터 수정(예: INSERT, UPDATE, DELETE) 기록과 해당 수정이 발생한 순차적 기록이 포함되어 있습니다.
• 복제 이벤트
  • 데이터 수정 사항을 복제 이벤트로 변환하는 MySQL 복제 프로세스에서 메인 서버의 바이너리 로그를 읽습니다.
  • 클라이언트가 메인 서버에서 데이터 삽입 또는 업데이트와 같은 데이터 변경 작업을 실행할 때마다 서버는 이러한 변경 사항을 바이너리 로그에 복제 이벤트로 기록합니다.
  • 이벤트는 데이터베이스에 대한 변경 사항을 나타내며 복제를 위해 레플리카 서버로 전송됩니다.
• 복제 채널
  • 복제는 비동기식으로 발생할 수 있습니다. 즉, 메인 서버에서 변경된 내용이 레플리카 서버에 즉시 반영되지 않습니다.
  • 각 레플리카는 복제 채널을 사용하여 메인에 연결합니다. 이를 통해 복제 이벤트를 수신하고 자체 데이터베이스에 독립적으로 적용할 수 있습니다.
• 레플리카에 변경사항 적용
  • 레플리카 서버에서는 메인으로부터 수신된 복제 이벤트를 로컬 데이터베이스에 적용합니다.
  • 이 프로세스에는 메인에서 수행된 것과 동일한 데이터 수정(INSERT, UPDATE, DELETE)을 실행하여 레플리카 데이터베이스를 메인과 동기화된 상태로 유지하는 작업이 포함됩니다.
• 데이터 복제
  • 메인의 바이너리 로그에서 복제 이벤트를 읽고 이를 레플리카에 보내는 역할을 담당하는 I/O 스레드가 있고, 슬레이브에서 이러한 이벤트를 실행하는 역할을 하는 SQL 스레드가 있습니다.
    • IO 스레드: IO(입력/출력) 스레드는 슬레이브 서버에서 실행됩니다. 메인 서버에 연결하여 메인으로부터 바이너리 로그 이벤트를 요청하고 이를 레플리카의 릴레이 로그에 기록합니다.
    • SQL 스레드: SQL 스레드는메인 서버와 레플리카 서버 모두에서 실행됩니다. 메인에서는 바이너리 로그에서 이벤트를 읽고 실행하여 변경 사항을 적용합니다. 레플리카에서는 릴레이 로그에서 이벤트를 읽고 이를 실행하여 레플리카 데이터베이스에 동일한 변경 사항을 적용합니다.
  • 레플리카의 IO 스레드는 마스터에서 바이너리 로그 이벤트를 지속적으로 가져와 릴레이 로그에 기록합니다.
  • 레플리카의 SQL 스레드는 릴레이 로그에서 이벤트를 읽고 이를 실행하여 레플리카 데이터베이스에 동일한 변경 사항을 적용합니다.
  • 따라서 레플리카의 데이터가 메인의 데이터와 일관성을 유지하도록 보장합니다.

 

Weakness

• 데이터 불일치 위험
  • MySQL Replication은 비동기 방식을 사용합니다.
  • 메인 서버에서 트랜잭션은 바이너리 로그에 저장되고, 레플리카 서버는 주기적으로 바이너리 로그를 요청합니다. 비동기 복제 방식에서는 레플리카로 바이너리 로그에 저장된 이벤트가 전달되었는지, 실제로 적용이 되었는지 보장하지 않습니다.
  • 또한, 비동기 복제 방식에서는 소스에서 데이터를 변경한 직후 레플리카를 조회하면, 변경 전 내용이 조회될 수 있습니다. 일반적으로는 200~300ms 이내로 소스의 변경내용이 레플리카에도 적용되지만, 실시간성이 매우 중요한 쿼리의 경우는 메인 서버로 직접 읽기 요청을 보내는 것이 좋습니다.
  • 따라서 소스 서버에 장애 발생 시 레플리카 서버로 이벤트가 제대로 전달되지 않을 수 있습니다. 즉, 복제에서 누락이 발생할 수 있다는 것을 의미하며, 만약 메인 서버 장애시 조치를 위해 레플리카를 승격하면 레플리카에서 누락된 데이터를 찾고, 필요시 레플리카에 누락분을 수동으로 반영해야 합니다.
• 네트워크 종속성
  • DB 복제는 메인 서버와 레플리카 서버 간의 네트워크 연결에 크게 의존합니다. 네트워크 안정성, 대역폭 제한 또는 대기 시간과 관련된 문제는 복제 프로세스에 영향을 미치고 데이터 복제가 지연되거나 실패할 수 있습니다.

 

DB replication 적용: https://ws-code-diary.tistory.com/68

MySQL Replication 구축

 

참고자료

https://hudi.blog/mysql-replication-synchronous-type/