GitHubAboutDocsTech-Log

Replication(레플리케이션)

서비스에서 발생하는 대용량 트래픽을 안정적으로 처리하기 위해 데이터베이스 서버의 확장이 필수적인데, 이를 해결하기 위해 사용되는 방법 중 하나가 Replication이다. 레플리케이션은 한 서버에서 다른 서버로 데이터가 동기화되는 것을 말하며, 원본 데이터를 가진 서버를 소스(source) 서버, 복제된 데이터를 가지는 서버를 레플리카(Replica) 서버라고 부른다.

목적

일반적으로 서비스에서 사용될 DB 서버를 구축할 때 소스 서버 한 대, 복제를 위한 레플리카 서버를 한 대 이상 구축한다. 이는 스케일 아웃의 목적 외에도 다음과 같은 목적을 가지고 있다.

  1. 스케일 아웃(Scale-out): DB 서버로 유입되는 트래픽도 증가하면 자연히 부하가 발생하기 때문에, 스케일 업으로는 한계가 있어 여러 대의 서버로 분산하여 처리하는 스케일 아웃이 필요하다.

  2. 데이터 백업: 사용자나 개발자의 실수로 데이터가 삭제되는 것에 대비해 데이터 백업을 레플리카 서버에서 수행하여 데이터를 보호한다.

  3. 데이터 분석: 대량의 데이터를 대상으로 집계 연산을 하면 소스 서버에 부하가 발생하므로, 레플리카 서버에서 집계 연산을 수행한다.

  4. 데이터의 지리적 분산: 레플리카 서버를 여러 지역에 구축하여 지역별로 데이터를 분산하여 처리한다.

복제 아키텍처

MySQL 서버에서 발생하는 모든 변경 사항은 바이너리 로그로 기록되는데, 이 로그에는 데이터의 변경 내역뿐만 아니라 데이터베이스나 테이블의 구조 변경과 계정이나 권한 변경 정보까지 모두 기록된다. 레플리케이션은 바이너리 로그에 기록된 변경 정보들(=이벤트) 기반으로 동작하며, 소스 서버에서 발생한 바이너리 로그를 레플리카 서버로 전송하여 레플리카 서버에서도 동일한 변경 사항을 수행하여 데이터를 동기화한다.

위 동작은 MySQL의 세 개의 스레드에 의해 수행하는데, 하나는 소스 서버에 존재하고 나머지 두 개는 레플리카 서버에 존재한다.

  • 바이너리 로그 덤프 스레드(Binary Log Dump Thread): 소스 서버에서 바이너리 로그를 읽어 레플리카 서버로 전송하는 스레드

  • 레플리케이션 I/O 스레드(Replication I/O Thread): 레플리카 서버에서 소스 서버로부터 전송받은 바이너리 로그 이벤트를 가져와 레플리카 서버의 릴레이 로그에 기록하는 스레드

  • 레플리케이션 SQL 스레드(Replication SQL Thread): 레플리카 서버의 릴레이 로그에 기록된 이벤트를 레플리카 서버의 데이터베이스에 실행하는 스레드

각 스레드는 독립적으로 동작하기 때문에, 한 스레드에서 문제가 발생하더라도 다른 스레드는 정상적으로 동작한다.(하지만 소스 서버로부터 동기화되지 못하기 때문에 데이터가 불일치 상태가 된다.)

복제 타입

레플리케이션은 소스 서버의 바이너리 로그에 기록된 변경 내역을 식별하는 방식에 따라 아래 두 가지로 나뉜다.

  • 바이너리 로그 파일 위치 기반 복제

    • 레플리케이션이 처음 도입됐을 때 사용한 방식

    • 소스 서버의 바이너리 로그 파일명과 파일 내 위치(Offset)를 기반으로 개별 바이너리 로그 이벤트를 식별하여 복제 수행

  • 글로벌 트랜잭션 아이디 기반 복제

    • MySQL 5.6부터 도입된 방식, MySQL 8.0까지 계속해서 개선되고 있는 방식

    • 모든 MySQL 서버에서 공통으로 사용하는 글로벌 트랜잭션 아이디(GTID)를 기반으로 개별 바이너리 로그 이벤트를 식별하여 복제 수행

    • GTID는 바이너리 로그 파일명과 파일 내 위치(Offset)에 의존하지 않기 때문에,바이너리 로그 파일명과 파일 내 위치(Offset) 정보가 변경되더라도 레플리케이션을 계속 수행할 수 있다.

참고자료

Last updated

Was this helpful?