Mariadb 리플리케이션(Replication) 은 어떻게 동작하는 걸까?

2022.11.22 - [개발/MariaDB] - MariaDB 리플리케이션(Replication) 이해 및 구축(Rocky Linux)

지난 포스팅에서 아래와 같은 부분을 살펴봤습니다.

• 리플리케이션이 필요한 이유
• 리플리케이션 구축 방법
• 리플리케이션 동작 원리

리플리케이션 동작원리에 대해 설명이 좀 부탁하다 생각 들어 내용을 좀 더 보강해보려 합니다.

[그림1] 리플리케이션 동작 흐름

[그림 1] 은 리플리케이션 동작의 흐름을 도표로 표현한 것입니다. 

예시로 마스터의 데이터베이스에 row 한 개를 inset 했다고 가정하고 흐름을 이야기해볼까 합니다. 

Binary Log

바이너리 로그 또는 빈로그(bin Log)라고 불립니다. 

마스터의 데이터베이스에 데이터 또는 스키마가 변경되는 이벤트를 저장하는 공간입니다. 
데이터베이스에 row 한 개가 insert 되면 데이터 베이스에 저장 후 바이너리 로그에 inset에 대한 이벤트들이 저장됩니다.

[그림2] 바이너리 로그 파일들

MariaDB 데이터 폴더를 가시면 위의 이미지 파일들이 Binaly Log 파일들입니다.

$ vi /etc/my.cnf.d/server.cnf 
 
[mysqld]
# replication setting (master)
server_id=1
log-bin=mysql-bin
binlog-format=row
expire_logs_days=30

지난 포스팅에서 마스터 설정을 위와 같이 했었죠. 

binlog-format 설정값으로는 statement, row, mixed 로 설정할 수 있습니다.
설정값에 의해 바이너리 로그에 어떤 형태로 이벤트를 저장할 것인가를 결정하게 됩니다.

• Statement-baseed Type
  SQL(쿼리)을 그래도 바이너리 로그에 기록하게 됩니다. 그리고 슬레이브도 같은 SQL를 실행하게 되죠. 
  바이너리 로그 사이트가 작으나, inset 시 랜덤 값을 넣어라 의 쿼리를 실행하게 되면 마스터와 슬레이브의 데이터가 달라질 수 있습니다. 
• Row-based type
  변경된 row 데이터 자체를 base64로 인코딩하여 바이너리 로그에 기록합니다. 
  변경된 값이 많으면 로그 파일 자체가 커지는 단점이 존재합니다. 
• Mixed type
  statement와 Row의 혼용해서 사용하는 type입니다. 기본적으로 Statement로 실행되다가 상황에 따라 Row Type으로 바이너리에 저장하게 됩니다. 

저는 Row 타입만 사용하고 있는데, 무엇이 됐든 마스터에 변경된 데이터 또는 쿼리를 저장해놓는 곳이 바이너리 로그입니다. 

 

Dump Thread 

덤프 스레드 또는 마스터 스레드라고 불립니다. (여기는 덤프 스레드로 호칭하겠습니다)

덤프 스레드의 역할은 슬레이의 IO 스레드가 요청을 하면 바이너리 로그에서 기록을 읽고 IO 스레드에게 데이터를 전달하게 됩니다. 

 

IO Thread

mysql> CHANGE MASTER TO MASTER_HOST = '192.168.0.1', MASTER_USER='replication_user1', MASTER_PASSWORD = 'pw123!@#'
mysql> CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.003371', MASTER_LOG_POS=71120585

이전 포스팅에서 슬레이브에 마스터의 계정을 이용하여 리플리케이션 구성을 했었습니다. 
이 계정이 덤프 스레드와 IO 스레드의 통신을 할 수 있는 역할을 합니다.
IO 쓰레드는 덤프 스레드에게 데이터를 요청하여 받은 데이터를 릴레이 로그에 저장합니다. 

SQL Thread

SQL 스레드의 역할은 릴레이 로그의 기록을 읽어와서 Database에 실행을 하는 역할을 합니다.
IO 스레드보다 SQL스레드가 처리하는 시간이 깁니다.
마스터에 데이터를 입력하면 실제 슬레이브의 데이터베이스에 적용하는 시간이 상황에 따라 길어질 수도 있습니다.
이 시간을 단축 시키는 방안이 mariadb에서는 Parallel replication을 소개하고 있습니다.

참고 : https://mariadb.com/kb/en/parallel-replication/

아직 저도 적용하기 전이라서 더 깊이 이야기하지는 못하겠습니다.

 

정리

말이 좀 길어졌는데, 요약하면 다음과 같습니다.

1. 마스터에서 데이터 변경(inset, update 등)이 일어나면 마스터에 데이터베이스에 반영합니다. 
2. 마스터에서 변경된 이력을 Binary Log에 기록 후 관련 이벤트를 슬레이브에 전달합니다. 
   
   [슬레이브]
3. 슬레이브는 IO_THREAD에서 마스터 이벤트를 감지하고 마스터의 덤프 스레드에게 데이터를 요청합니다.
4. 마스터의 덤프 스레드는 바이너리 로그의 기록을읽어 IO 스레드에게 전달해줍니다.
5. IO 쓰레드는 전달받은 데이터를 릴레이 로그에 저장합니다.
6. SQL 스레드는 릴레이 로그를 읽고 슬레이브의 데이터베이스에 반영합니다.