Replication Architecture

MySQL 서버에서 발생하는 모든 변경 사항은 바이너리 로그(Binary Log)에 순서대로 기록된다.

바이너리 로그에는 데이터의 변경 내역뿐만 아니라 DB나 테이블 구조 변경과 계정, 권한의 변경 정보까지 모두 저장된다.

복제는 이 로그를 기반으로 구현됐는데, 소스 서버에서 생성된 바이너리 로그가 레플리카 서버로 전송되고 레플리카 서버에서는 해당 내용을 로컬 디스크에 저장한 뒤 자신이 가진 DB에 반영하여 소스 서버와 레플리카 서버 간 데이터 동기화가 이뤄진다.

레플리카 서버에서 소스 서버의 바이너리 로그를 읽어서 로컬 디스크에 저장한 파일을 릴레이 로그(Relay Log)라고 한다.

MySQL 복제는 3개의 스레드에 의해 동작하는데, 이 중 하나는 소스 서버에, 나머지 두 개는 레플리카에 존재한다.

1. Binary Log Dump Thread:

레플리카 서버는 데이터 동기화를 위해 소스 서버에 접속해서 바이너리 로그 정보를 요청한다.

소스 서버에서 레플리카 서버가 연결될 때 내부적으로 바이너리 로그 덤프 스레드를 생성해서 바이너리 로그의 내용을 레플리카 서버로 전송한다.

바이너리 로그 덤프 스레드는 레플리카 서버에 보낼 이벤트를 읽을 때 일시적으로 바이너리 로그에 잠금을 수행하며, 읽고 난 후 바로 잠금을 해제한다. (소스 서버에서 SHOW PROCESSLIST 명령으로 확인)

1. Replication I/O Thread:

복제가 시작(start slave)되면 레플리카 서버는 I/O 스레드를 생성하고 복제가 멈추면(stop slave) I/O 스레드는 종료된다. I/O 스레드는 소스 서버의 바이너리 로그 덤프 스레드로부터 바이너리 로그 이벤트를 가져와 릴레이 로그(로컬 서버 파일)로 저장하는 역할을 담당한다.

소스 서버의 바이너리 로그를 읽어 파일로 쓰는 역할만 하기 떄문에 “I/O” 스레드라고 명명된 것이다.

1. Replication SQL Thread:

SQL 스레드는 I/O 스레드에 의해 작성된 Relay Log 파일의 이벤트를 읽고 실행한다.

쉽게 얘기하면, 레플리카 서버에서는 전송받은 로그를 Relay Log에 기록하고 SQL 스레드가 이를 읽어서 적용한다. 이 과정에서 릴레이 로그에 대한 잠금이 발생한다. (릴레이 로그에 저장된 트랜잭션 이벤트들을 레플리카 서버에 적용)

레플리카 서버에서 Replicaiton I/O 스레드와 SQL 스레드는 독립적으로 동작한다. 그러므로 SQL 스레드에서 이벤트를 적용하는 게 느려도 I/O 스레드는 정상적으로 빠르게 소스 서버로부터 이벤트를 읽어올 수 있다.

또한 레플리카 서버에서 소스 서버의 변경 사항들이 적용되는 것은 소스 서버와 독립적으로 동자갛기 때문에 레플리카 서버에 문제가 생겨도 소스 서버에는 영향을 받지 않는다.

하지만 소스 서버에 문제가 생겨서 레플리카 서버의 I/O 스레드가 정상 동작 하지 않으면, 복제는 에러를 발생시키고 중단된다. 이는 레플리카 서버의 복제 기능만 중단된 것이기 때문에 레플리카 서버에서 쿼리를 처리하는 데 아무런 문제가 없다. 다만 데이터 동기화가 되지 않을 뿐이다.

복제가 시작되면 다음과 같이 총 3가지 유형의 복제 관련 데이터를 생성한다.

1. Relay Log:

릴레이 로그는 Replication I/O Thread에 의해 작성되는 파일로, 소스 서버의 바이너리 로그에서 읽어온 이벤트(트랜잭션) 정보가 저장된다.

바이너리 로그와 마찬가지로 현재 존재하는 Relay Log 파일들의 목록이 담긴 Index 파일과 실제 이벤트 정보가 저장돼 있는 로그 파일들로 구성된다.

1. Connection Metadata:

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

1. Applier Metadata:

Relay Log에 저장된 소스 서버의 이벤트들을 레플리카 서버에 적용하는 컴포넌트를 어플라이어(Applier)라고 한다.

어플라이어 메타데이터는 최근 적용된 이벤트에 대해 해당 이벤트가 저장돼 있는 릴레이 로그 파일명과 파일 내 위치 정보 등을 담고 있으며, Replication I/O Thread는 이 정보들을 가지고 레플리카 서버에 나머지 이벤트들을 적용한다. mysql.slave_relay_log_info 테이블에 저장된다.

커넥션 및 어플라이어 메타데이터는 FILE 혹은 TABLE 형태로 데이터를 관리할 수 있다.

MySQL 8.0.2 버전부터 디폴트가 TABLE로 변경도ㅒㅆ으며, FILE은 제거 될 예정이다.

FILE이 기본값 이었던 때는 Replication I/O Thread와 SQL Thread가 동작할 때 두 파일의 내용이 동기화되지 않는 경우가 빈번하게 발생했다.

• ex) 레플리카 서버가 비정상 종료되는 경우 실제 적용된 바이너리 로그 위치와 파일에 저장된 위치가 일치하지 않거나 파일 자체가 손상되어 복제가 재시작되지 못하는 경우 발생

TABLE로 설정하면 두 정보 모두 InnoDB 스토리지 엔진 기반의 테이블로 관리되고, 특히 Replication SQL Thead가 트랜잭션을 허용할 때, slave_relay_log 테이블의 데이터도 같은 시점에 아토믹(Atomic)하게 업데이트되므로 예상하지 못하게 MySQL이 갑자기 종료되어도 다시 구동했을 때 문제없이 복제가 진행될 수 있다.

이를 크래시 세이프 복제(Crash-Safe Replication)이라고 한다.