MySQL 복제(Replication)

MySQL의 Replication 은 'Scale Out' 아키텍처를 사용하여 대규모 고성능 애플리케이션을 구축하는 기반이 된다. 
Replication을 통해 하나 이상의 서버를 다른 서버의 구성하여 데이터를 복사 및 동기화할 수 있다.
Replication 은 아래와 같은 수많은 작업들을 위한 전략의 초석이 되기도 한다.   

• High Availability
• Scalability
• DisasterRecovery
• Backup
• Analysis
• DataWareHouse

 

개요

Replication 은 한 서버에서 다른 서버로 데이터가 동기화되는 것을 의미한다.

• Source Server : 원본 데이터를 가진 서버
• Replica Server : 원본으로부터 복제된 데이터를 가지는 서버

 

복제 서버를 구축하는 이유

1. 스케일 아웃 : 쿼리를 분산시켜 늘어나는 트래픽을 대응하는데 유연해진다.
2. 데이터 백업 : 휴면 에러로 인한 데이터 삭제에도 Replica 서버에서 복구가 가능하다.
3. 데이터 분석 : 데이터 분석용 쿼리는 대량의 데이터를 조회하는 경우가 많고,
   또 집계 연산을 하는 등 쿼리 자체가 굉장히 복잡하고 무거운 경우가 대부분이라서 서버의 리소스를 많이 사용하는데
   여분의 Replica 서버를 구축해 분석용 쿼리만 전용으로 실행될 환경을 만드는 것이 가능하다.
4. 데이터의 지리적 분산 : 애플리케이션과 비교적 가까운 위치에 두어 통신 시간을 줄임으로써 성능을 높일 수 있다.
5. 고가용성 및 장애 조치 : Replica를 둠으로써 SPOF(Single Point Of Failure)를 방지하며 다운 타임을 줄일 수 있다.
6. 테스트 : Replica를 업그레이드할 타겟 버전으로 올려봄으로써 버전 테스트가 가능하다.

 

복제 아키텍처

MySQL 복제는 바이너리 로그를 기반으로 구현하고 있다.
MySQL 복제 방법을 간단히 표현하자면 아래와 같다.

1. Source는 데이터의 변경 사항을 바이너리 로그에 '바이너리 로그 이벤트'로 기록한다.
2. Replica는 Source의 바이너리 로그 이벤트를 자체 로컬 릴레이 로그에 복사한다.  
3. Replica는 릴레이 로그의 이벤트를 재생하여 자체 데이터에 변경사항을 적용한다. 

 

용어 정리(로그)

• 바이너리 로그 :
  • MySQL에서 발생하는 모든 변경사항을 순서대로 기록한 파일
  • 데이터 변경 내역뿐만 아니라 스키마나 테이블의 구조 변경과 계정이나 권한의 변경 정보까지 모두 저장된다.
  • 이벤트 : 바이너리 로그에 기록된 각 변경 정보들을 일컫는 말

 

•  릴레이 로그 :
  • Replication I/O Thread에 의해 작성되는 파일로, 바이너리 로그 이벤트 정보 저장한 파일
  • 바이너리 로그와 마찬가지로
    릴레이 로그 파일들의 목록이 담긴 인덱스 파일과 실제 이벤트 정보가 저장돼 있는 로그 파일들로 구성된다.
  • 릴레이 로그에 저장된 트랜잭션 이벤트들은 Replication SQL Thread에 의해 레플리케이션 서버에 적용된다.

 

용어 정리(스레드)

• Binary log Dump Thread :
  • Replica와 바이너리 로그 이벤트 정보를 Replica 서버로 전송하기 위한 스레드
  • Source 서버 내부적으로 생성되는 스레드이다.
  • Replica 서버로 보낼 각 이벤트를 읽을 때, 일시적으로 바이너리 로그에 잠금을 수행한다.
  • 이벤트를 모두 읽고 난 후에는 잠금을 해제한다.

 

• Replication I/O Thread :
  • 복제 시작 시 생성되며, 바이너리 로그 이벤트를 가져와 로컬 서버의 파일로 저장하는 역할
  • 복제가 시작되면 Replica 서버는 Replication I/O Thread를 생성하고, 복제가 멈추면 스레드는 종료된다.
  • 소스 서버의 바이너리 로그를 읽어서 파일로 쓰는 역할만 수행하기에 Replication I/O Thread라고 것이다.

 

• Replication SQL Thread :
  • Replication I/O Thead에 의해 Replica 서버 로컬에 작성된 릴레이 로그 파일의 이벤트들을 읽고 실행하는 역할

 

용어 정리(이외에도)

• Connection Metadata : 
  • Replication I/O Thread에서 연결할 때 사용하는 DB 계정 정보 및
    현재 읽고 있는 Source 서버의 바이너리 파일명과 파일내 위치 값(File Offset) 등이 담겨 있다.
  • 이러한 정보는 기본적으로 mysql.slave_master_info 테이블에 저장된다.

 

• Applier Metadata : 
  • Replication SQL Thread에서 릴레이 로그에 저장된 Source 서버의 이벤트들을
    Replica 서버에 적용하는 컴포넌트를 한다.
  • Applier Metadata는 최근 적용된 이벤트에 대해
    해당 이벤트가 저장돼 있는 릴레이 로그 파일명과 파일 내 위치 정보 등을 담고 있으며
    Replication SQL Thread는 이 정보들을 바탕으로 Replica 서버에 나머지 이벤트들을 적용한다.
    이 정보는 기본적으로 mysql.slave_relay_log_info 테이블에 저장된다.

 

복제 타입

1. 바이너리 로그 파일 위치 기반 복제
2. 글로벌 트랜잭션 ID 기반 복제

 

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

 

글로벌 트랜잭션 ID 기반 복제

바이너리 로그 파일 위치 기반 복제 방식을 사용하면
각각의 이벤트들이 바이너리 로그 파일명과 파일 내 위치값의 조합으로 식별이 된다.
하지만, 문제는 이 같은 ‘식별’ 기능 자체가 최초의 Source 서버에 한해서만 유효하다는 것이다.

동일한 이벤트가 Replica 서버에서도 동일한 파일명과 동일한 위치에 저장된다는 보장이 없다.
한마디로 복제에 투입된 서버 환경 설정에 따라 동일한 이벤트에 대해 서로 다른 식별값을 가질 수 있다.

단순히 생각하면 큰 문제가 없을 것이라 판단할 수 있는데
만일 Source 서버에 장애가 발생했고, Replica 서버중 한대가 Source로 승격이 되는 과정에서
앞서 말한, 동일한 파일명, 동일한 위치과 같은 환경설정이 다르면 정상 동작하기 어려워진다.

앞서 ‘서버 환경 다름’에 의한 문제를 해결을 할 수는 있지만
자동화가 아닌, 복제 토폴리지를 수동으로 이로 인한 DownTime 및 FailOver 시간이 길어질 수 있다.
또한, 토폴로지를 변경하는 과정에서 운이 안 좋으면 이벤트가 중복될 수도, 이벤트를 건너뛸 수도 있다.

이 같은 문제를 해결하기 위 MySQL 5.7 버전에서부터 GTID(Global Transaction ID)가 도입되었다.

 

GTID의 필요성

GTID 필요성과 관련해서 예시를 들면서 설명을 진행하고자 한다.

초창기 복제 토폴로지 형태

최초 복제 토폴로지 구성은 다음과 같다.

• Source Server :
  • 바이너리 로그를 생성하는 주체이다.
  • Query Offloading 구성으로 insert, update, delete 처리를 맡고 있다.

 

• Replica Server 1 :
  • Source Server와 동기화된 상태이다.
  • Query Offloading 구성으로 실제 Read 역할을 맡고 있다.

 

• Replica Server 2 :
  • Source Server와 완전 동기화되지 않은 상태이다.
  • 통계용 Replica 서버로

 

Source Server 에 장애가 발생했다.

Source Server 에 장애가 발생하면 Replica Server 중 한대가 Source Server로 승격되어야 한다.
일반적으로, Read를 수행하는 Replica Server 1 이 Source Server로 승격이 될 테지만
모든 Query를 처리하는 형태가 되어 상당한 부하가 발생할 것이고 머지않아 해당 서버도 다운될 수 있다.

이 같은 문제를 해결하기 위해서는, Replica Server 2를 Read 용도로 사용해야 한다.
하지만, Replica Server 2는 동기화가 되지 않은 상태에서 종료가 되었으니 최종시점까지 동기화할 방법이 없다.
(앞서 말했던 서버 BinaryLog 환경 구성이 다르다던가, 고친다 해도 수동으로 일일이 작업을 해줘야 한다.)

---

GTID를 사용한다면 다음과 같다.

• Source Server :
  • 현재 GTID는

• Replica Server 1 :
  • Source Server와 동기화된 상태이다.
  • 현재 GTID는

 

• Replica Server 2 :
  • Source 동기화되지 않은 상태이다.
  • 현재 GTID는

 

Source Server 에 장애가 발생했다.

• C 서버에서 아래와 같은 명령어를 통해 Source Server에 대한 정보를 변경한다.
  • CHANGE REPLICATION SOURCE TO SOURCE_HOST = "New Source Server"
  • CHANGE MASTER TO MASTER HOST = "New Source Server"

 

• 앞선 방식과의 차이점은 바이너리 로그의 위치 및 파일명에 신경을 쓰지 않아도 된다.
• 그리고 바이너리 로그 파일에서 어느 위치부터 이벤트를 가져올지도 입력하지 않아도 된다.
  • Source / Replica 1에서 이미 Replica 2 GTID를 실행한 기록이 있기에 이후 로그 이벤트를 가져오면 된다.

 

GTID를 사용함으로써, 앞선 바이너리 로그 파일 위치 기반 복제 보다 장애 회복에 있어 많은 시간을 단축할 수 있다.
또한 장애뿐만 아니라, DB 서버 확장에 있어서도 동일한 환경을 구성해야 하는 제약도 사라져 생산성에 기여할 수 있다.

복제 데이터 포맷

MySQL 은 복제를 위해 명령문 기반, 행 기반, 혼합의 3가지 바이너리 로그 형식을 제공한다.
바이너리 로그 형식이라 함은 변경 이벤트들이 바이너리 로그에 어떤 형태로 저장되는지를 의미한다.

Replica Server는 Source Server의 바이너리 로그 이벤트를 내부적으로 가공하지 않고
그대로 실행해 자신의 데이터에 적용하므로, 복제에서 어떤 바이너리 로그 포맷을 사용하는지는 중요하다.

1. Statement 기반 바이너리 로그 포맷
2. Row 기반 바이너리 로그 포맷
3. Mixed 포맷

 

Statement 기반 바이너리 로그 포맷

MySQL에 바이너리 로그가 처음 도입 되었을 때부터 존재했던 포맷으로
변경 이벤트에 대해서 이벤트를 발생시킨 SQL문을 바이너리 로그에 기록하는 포맷이다.

즉, Source Server에서 데이터를 변경한 쿼리를 기록하는 것을 의미하며
Replica Server는 릴레이 로그에서 이벤트를 읽고 실행할 때 Source Server 가 실행한 실제 SQL을 다시 실행한다.

단 몇 가지 단점들이 존재한다.

• Repeatable Read 트랜잭션 격리 수준에서만 사용이 가능하다.
• SQL 문을 그대로 사용하기에, 락을 사용하는 쿼리가 있을 경우 성능 저하를 유발할 수 있다.

 

Row 기반 바이너리 로그 포맷

MySQL 5.1 버전부터 도입되었으며 MySQL 5.7.7부터 기본 복제 방식으로 사용되는 포맷이다.
Source Server에서 데이터 변경이 발생했을 때 '변경된 값' 자체가 바이너리 로그에 기록되는 방식이다.

쉽게 설명하자면, Statement 기반 바이너리 로그 포맷 은 쿼리를 실행하기에
UUID(), USER()와 같은 비확정적 메서드가 실행되면 멱등성 및 데이터 일관성을 보장하기 어렵다.

Row 기반 바이너리 로그 포맷은 Source Server에서 비확정적 함수를 사용해도,
실제 함수의 '결괏값'만을 바이너리 로그에 넣기 때문에 안전한 복제, 일관성 있는 복제가 이루어진다.
쿼리도 마찬가지로, 쿼리의 결과가 들어오기에 Lock 실행이 최소화되어 처리된다.

참고로 Row 기반 바이너리 로그 포맷 은 모든 트랜잭션 격리 수준에서 사용가능하며,
MySQL 서버의 바이너리 로그 포맷이 Row 기반 바이너리 로그 포맷으로 설정되어 있다 하더라도
사용자 계정 생성과 권한 부여 및 회수, 그리고 테이블 뷰, 트리거 생성등과 같은 DLL문은 전부
Statement 기반 바이너리 로그 포맷으로 바이너리 로그에 저장된다.

Row 기반 바이너리 로그 포맷도 단점은 존재한다.

• 결괏값으로 나온 데이터의 양이 많은 경우, 네트워크 통신 시 성능 저하가 일어난다.

MySQL에서는 이 같은 문제를 해결하기 위해 binlog_row_image라는 시스템 변수 제공한다.
ROW 포맷을 사용할 경우, 바이너리 로그에는 각 변경 데이터마다 변경 전 레코드와 변경 후 레코드가 함께 저장된다.
binlog_row_image 시스템 변수는 각 변경 전후 레코드들에 대해 테이블의 어떤 칼럼을 기록할 것인지를 결정한다.

• full : 모든 레코드 칼럼 기록
• minimal : 변경 데이터에 대해 필요한 값만 기록
• noblob : full과 같으나, BLOB이나 TEXT 칼럼에 대해 변경이 발생하지 않은 경우 해당 칼럼들에 대해 기록하지 않음

 

Mixed 포맷

2가지 바이너리 로그 포맷을 혼합해서 사용하는 것으로
기본적으로 Statement를 사용하되, 실행된 쿼리와 스토리지 엔진의 종류에 따라 필요시 자동으로 Row 포맷 사용한다.

InnoDB의 경우

• Row 포맷 지원 여부 : 가능
• Statement 포맷 지원 여부 : 트랜잭션 격리 수준이 REPEATABLE or SERIALIZABLE 일 때

쿼리의 경우 대부분 Statement 포맷으로 기록될 가능성이 높다.
문제가 될 가능성이 있는 안전하지 못한 쿼리 형태면 ROW 포맷으로 작성된다.

언뜻 보면 두 방식의 장점을 결합하려고 시도하는 것 같지만
MySQL 내부적으로 설정된 기준을 통해 실행되므로 사용자가 원치 않는 결과를 얻을 수 있다.
따라서 상황에 따라 좋은 방향을 잘 고려하는 것이 좋을 것 같다.

 

복제 동기화 방식

MySQL에서는 소스 서버와 레플리카 서버 간의 복제 동기화에 대해 2가지 방식을 제공한다.

1. 비동기 복제
2. 반동기 복제

 

비동기 복제

MySQL의 기본 복제 프로세스는 비동기 복제 방식이다.
Source Server 가 Replica Server들이 변경 이벤트가 정상적으로 전달되어 적용되었는지 확인하지 않는 방식이다.

Source Server에서 커밋된 트랜잭션은 바이너리 로그에 기록된다.
Replica Server에서는 주기적으로 신규 트랜잭션에 대한 바이너리 로그를 요청한다.

비동기 방식의 경우, Replica Server에 동기화 여부를 확인하지 않으므로
Source Server에서 장애가 발생했을 시 누락되는 트랜잭션들이 생길 수 있다.
승격되는 과정에서 누락되는 트랜잭션도 있을 수 있으며 이 같은 문제를 해결하려면 직접 확인하고 수동으로 적용해야 한다.

하지만, 비동기 복제를 사용하는 이유는
Source Server 가 각 트랜젝션에 대해 레플리카 서버로 전송되는 부분을 고려하지 않기 때문에
트랜잭션 처리에 있어서 더 빠른 성능을 보이고, Replica Server에 문제가 생겨도 Source Server에 전파되지 않는다.
또한 Replica Server에 무거운 쿼리가 실행되어 성능 저하가 있어도 Source Server와 무관하니 통계용으로도 적합하다.

비동기 복제 방식은 Replica Server를 두어도 큰 성능 저하가 없으므로
Replica Server 확장에 유리해서 읽기 트래픽을 분산하는 용도로 제격이라 할 수 있다.

 

반동기 복제

MySQL 도입되어 비동기 복제보다 좀 더 향상된 무결성을 제공하는데 초점을 맞춘 복제 방식이다.

Source Server는 Replica Server로부터 변경 이벤트를 릴레이 로그에 기록 후 응답을 보내면
그때 트랜잭션을 완전히 커밋시키고 클라이언트에 결과를 반환한다.
즉, 반동기 복제에서는 적어도 하나의 Replica 트랜잭션이 ‘전송’되었음을 보장한다.
하지만, ‘전송’ 되었음을 보장하지 실제 적용 여부는 알 수 없으며 이름이 ‘반동기’로 명명된 이유다.

반동기 복제 시 응답 대기 형태

• After Sync :
  • Replica에 전송이 완료되면 Source Server의 Storage Engine에 Commit 한다.
  • 장점 :
    • 소스 서버에 장애가 발생 했을 때, 팬텀 리드(Phantom Read)가 발생하지 않는다.
    • 장애가 발생한 소스 서버에 대해 좀 더 수월하게 복구 처리가 가능하다.
    • After Commit 보다 좀 더 무결성을 강화시킨 방법이다.

 

• After Commit
  • Source Server의 Storage Engine에 Commit 한 후, 전송하고 결과를 기다린다.

 

복제 토폴로지

MySQL 은 뛰어난 확장성과 유연성을 통해 다양한 토폴로지를 쉽게 구현할 수 있다.
반면에, 메커니즘을 잘 이해하지 못하면 오히려 유지보수가 불가능한 토폴로지를 설계할 수 있다.
실제로 다른 인프라 영역의 복제 메커니즘을 그대로 사용하면 오히려 부하를 유발할 수도 있다.

MySQL의 복제 토폴로지는 요구 사항을 충족하면서 최대한 단순하게 유지하는 것이 좋다.
거의 모든 사례에 적용할 수 있는 토폴로지와 반대로 권장하지 않는 토폴로지에 대해서 정리해 본다.

 

권장하는 토폴로지

Active-Passive

Active-Passive

Active-Passve 토폴로지는 모든 읽기 및 쓰기를 단일 Source Server로 보낸다.
또한, 애플리케이션 트래픽을 능동적으로 처리하지 않는 소수의 패시브 레플리카를 유지 관리한다.

즉, 복제 Replica를 두지만 QueryOffloading 처리를 하지 않고
CRUD 쿼리에 대한 모든 작업을 Source Server에서 도맡는 토폴로지이다.
이 모델을 선택하는 주된 이유는 복제 지연으로 인한, 데이터 불일치 문제를 신경 쓰고 싶지 않을 때 사용한다.

Source Server와 Replica Server는 동일한 스펙으로
Replica 오롯이 Source Server의 대응하기 위한 용도로 사용하거나
통계와 같은 쿼리가 많은 지점에 사용하는 형태로 두는 것을 추천한다.

 

Active-StandBy 토폴로지(Single Replica)

Active-StandBy 토폴로지(Single Replica)

가장 기본적인 형태로, 제일 많이 사용되는 형태라고 볼 수 있다.
보통 Source Server 에만 직접 접근하고, Replica Server는 장애 발생 시 예비로 사용하기 위한 용도로 사용된다.
Query Offloading을 통해 Read와 다르게 가져갈 수 있는 구조다.
다만, 앞서 언급했듯이 장애가 발생하면 그 부하를 싱글 Replica Server 혼자서 감당해야 하는 리스크가 있다.

 

Active-StandBy 토폴로지(Multi Replica)

Active-StandBy 토폴로지(Multi Replica)

Active-StandBy 토폴로지의 싱글 레플리카 구성을 보안하기 위해 등장한 토폴로지다.
보조용 Replica Server를 한 대 더 두어 아래와 같은 역할을 맡도록 한다.

Source Server 장애 시

• Replica Server1 : New Source Server 역할로 승격되어 write 작업을 처리한다.
• Replica Server2 : Replica Server1 이 받는 Read 트래픽을 분산하여 처리한다.
• 복구된 Server 또는 새로운 Server :
  데이터 불일치로 인해, 복제할 대상이 되는 서버에 많은 데이터를 요청하고 이에 따라 쓰기 부하가 심해질 수 있다.
  이 경우 Source Server에 요청하는 것이 아니라, Replication Server를 통해 동기화를 진행하고
  이후, 실제 Source Server와 Replication 토폴로지로 맺는 방법으로 전환한다.

 

Active-StandBy 토폴로지(Chain Replica)

Active-StandBy 토폴로지(Chain Replica)

Active-StandBy 토폴로지(Multi Replica) 구성에서 레플리카 서버가 너무 많아
Source Server에 악영향을 미친다고 파악이 되면 1:M:N 구조도 고려해 볼 수 있다.

Source Server는 Replica Server에게 바이너리 로그 파일을 전달해야 하는데
비동기 방식을 사용한다 하더라도 수가 늘어나면 지연이 발생하기 마련이다.
이때 하나의 Replica Server를 다른 토폴로지를 위한 Source Server로 설정하고
이를 체이닝 방식으로 Replica Server를 하나씩 추가하는 방법이다.

 

Active-ReadPool

Active-ReadPool

Active-ReadPool 구성은 하나의 Source Server와 다수의 Replica Server Pool로 구성한다.

• 쓰기 작업은 Source Server로 보낸다.
• 읽기 작업은 애플리케이션 요구사항에 따라 Source / Replica Server로 보낸다.

Read Pool을 사용하면 읽기 집약적인 애플리케이션은 읽기를 수평으로 확장할 수 있지만
어느 시점이 지나면 Source Server에 대한 복제 요구로 인해 수평 확장이 떨어지게 된다.

 

권장하지 않는 토폴로지

Active-Active 모드의 이중 Source Server(Dual Source)

Active-Active 모드의 이중 Source Server(Dual Source)

이중 소스 복제(양방향 복제)는 Source와 Replica 한쌍의 공동 소스로 구성된 서버로 이루어진다.
이 토폴로지의 가장 위험한 부분은 쓰기 트래픽을 명시적으로 양쪽에 보낼 때이다.

• 각 서버마다의 쓰기 트래픽 + 동기화를 위해 사용되는 쓰기 트래픽이 중첩되어 부하 가중
• 동일한 레코드에 대해서 쓰기 작업이 일어났을 때 트랜잭션(동시성) 처리
• 데드락 발생 가능성 존재
• 복제 지연으로 인한 데이터 읽기 문제(원래 존재함)

 

각각의 Replica Server 가 있는 이중 Source Server

각각의 Replica Server 가 있는 이중 Source Server

동기화를 이루는 Source Server 가 2개 존재하며, 이들에 복제에 대한 Replica Server 가 있는 경우의 토폴로지

 

순환 복제(Ring Replication)

순환 복제(Ring Replication)

각각의 Source Server 가 서로 다른 Source Server를 바라보고 있고 이들의 참조관계가 순환인 토폴로지다.
토폴로지를 구성하는 어떠한 Server 라도 오프라인(다운)으로 전환이 되면
토폴로지를 구성하는 모든 Server에 영향을 주게 되고 업데이트 흐름이 중지가 된다.

 

멀티 소스 복제 구성

멀티 소스 복제 구성

토폴로지는 단순하게 유지하는 것이 중요하지만
일회성 기능을 처리하기 위해 고급 기능을 사용해야 하는 상황이 있을 수 있다.

예를 들어, 분리된 데이터베이스의 데이터를 병합하고 싶을 때
멀티 소스 복제를 사용하여 두 데이터 세트를 레플리카로 다시 가져올 수 있다.

앞서 언급했듯이 이 토폴로지는 특수한 사용 환경에 적합한 토폴로지이기에
이 개념을 중심으로 영구적인 MySQL 복제 토폴로지를 구축하는 경우는 권장하지 않는다.

+ (2022-12-27)

Multi-Master Replication 용도로 적용하거나 데이터가 분산 복제(Sharding)되고 있는 상황에서 전체 데이터에 대한 통계, 모니터링, 배치 작업 용도로 주로 구성되며, Transaction 수나 쓰기 Workload 크기, Network 지연에 따라 복제가 지연되는 문제가 심화될 수 있는 점을 인지하여야 한다.