MySQL Replication

소개 *

binary log 는 데이터의 변형 사항을 기록하는 로그 파일입니다. 
Table 에 대한 create, drop, truncate 와 Row 에 대한 insert, update, delete 에 대한 쿼리을 모두 기록합니다. 
해당하는 쿼리들은 binary format 으로 기록되기 때문에 binary log 라고 불립니다. 

MySQL Replication 은 Source MySQL 에 저장된 binary log 를 적극 활용합니다.
Replica MySQL 이 Source MySQL 의 binary log 내용들을 읽어들여 복제를 시도하죠.
 

이렇게 복제된 2개 이상의 데이터베이스가 가지는 여러 이점들이 있습니다.

먼저, 복제된 서버가 존재하기 때문에 가용성을 높일 수 있습니다.

그리고 읽기 요청에 대한 부하 분산이 가능해집니다.

 

아래 내용들에서 Replication 에 대해 알아보도록 하겠습니다.

Source-Replica 구조 *

데이터베이스 복제를 구현하기 위해서 Source-Replica 구조를 사용합니다.
Source-Replica 구조는 최소 2개의 서버를 필요로하며, Source MySQL 에 저장되는 데이터들을 Replica MySQL 이 복제하는 구조입니다. 
Source MySQL 은 전반적인 CRUD 요청에 대한 처리를 전담합니다.
요청된 생성, 수정, 삭제에 대한 처리를 책임지며, Source MySQL 의 테이블과 데이터들이 변형됩니다. 

흔히 DML, DDL 에 대한 처리가 Source MySQL 에서 처리되죠
Replica MySQL 은 Source MySQL 의 데이터 상태와 Sync 를 맞추며 Replication 상태를 유지합니다.

그리고 Source MySQL 와 Replica MySQL 모두 데이터 조회에 대한 요청을 처리할 수 있습니다.
그래서 Source-Replica 구조의 서버들을 최소 2개 이상 마련하여 읽기 요청에 대한 부하 분산을 할 수 있습니다.
 
Source MySQL 와 Replica MySQL 는 Pull 방식 으로 통신을 수행합니다.

자세한 내용은 아래 binary log dump 에서 설명하도록 하겠습니다.

bin log 확인하기 *

mysql query 로 대략적인 파일의 상태를 확인할 수 있습니다. 

show binary logs;
+---------------+-----------+-----------+
| Log_name      | File_size | Encrypted |
+---------------+-----------+-----------+
| binlog.000001 |   3039831 | No        |
| binlog.000002 |       180 | No        |
| binlog.000003 |       180 | No        |
| binlog.000004 |       180 | No        |
| binlog.000005 |       157 | No        |
+---------------+-----------+-----------+

 

log_bin_basename 인 시스템 변수를 조회함으로써 bin log 가 저장되는 파일의 위치를 알 수 있습니다. 

show variables like '%log_bin_basename%';
+------------------+-----------------------+
| Variable_name    | Value                 |
+------------------+-----------------------+
| log_bin_basename | /var/lib/mysql/binlog |
+------------------+-----------------------+

 

아래 내용은 test 라는 이름의 테이블을 생성하고 삭제한 결과에 해당하는 binlog 입니다.

내용은 길지만 간단히 요약하면

 

1. use `mysql`

2. create table test

3. drop table test

 

으로 정리되며,

테이블에 대한 DDL 이 기록에 남게됩니다.

 

mysqlbinlog /var/lib/mysql/binlog.000002

>> 

use `mysql`/*!*/;
SET TIMESTAMP=1694525546/*!*/;
SET @@session.pseudo_thread_id=10/*!*/;
SET @@session.foreign_key_checks=1, @@session.sql_auto_is_null=0, @@session.unique_checks=1, @@session.autocommit=1/*!*/;
SET @@session.sql_mode=1168113696/*!*/;
SET @@session.auto_increment_increment=1, @@session.auto_increment_offset=1/*!*/;
/*!\C latin1 *//*!*/;
SET @@session.character_set_client=8,@@session.collation_connection=8,@@session.collation_server=255/*!*/;
SET @@session.lc_time_names=0/*!*/;
SET @@session.collation_database=DEFAULT/*!*/;
/*!80011 SET @@session.default_collation_for_utf8mb4=255*//*!*/;
/*!80013 SET @@session.sql_require_primary_key=0*//*!*/;
create table test (a varchar(1000))
/*!*/;
# at 359
#230912 13:33:13 server id 1  end_log_pos 436 CRC32 0xfb448872 	Anonymous_GTID	last_committed=1	sequence_number=2	rbr_only=no	original_committed_timestamp=1694525593316264	immediate_commit_timestamp=1694525593316264	transaction_length=208
# original_commit_timestamp=1694525593316264 (2023-09-12 13:33:13.316264 UTC)
# immediate_commit_timestamp=1694525593316264 (2023-09-12 13:33:13.316264 UTC)
/*!80001 SET @@session.original_commit_timestamp=1694525593316264*//*!*/;
/*!80014 SET @@session.original_server_version=80034*//*!*/;
/*!80014 SET @@session.immediate_server_version=80034*//*!*/;
SET @@SESSION.GTID_NEXT= 'ANONYMOUS'/*!*/;
# at 436
#230912 13:33:13 server id 1  end_log_pos 567 CRC32 0x71af6cdb 	Query	thread_id=12	exec_time=0	error_code=0	Xid = 99
SET TIMESTAMP=1694525593/*!*/;
SET @@session.pseudo_thread_id=12/*!*/;
DROP TABLE `test` /* generated by server */
/*!*/;
SET @@SESSION.GTID_NEXT= 'AUTOMATIC' /* added by mysqlbinlog */ /*!*/;
DELIMITER ;
# End of log file
/*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=0*/;

 

binary log dump thread **

binary log dump 는 Source MySQL 가 Replica MySQL 에게 binlog 의 변경 사항을 제공하는 작업을 의미합니다.

binary log dump 과정에서 Replica MySQL 은 Source MySQL 의 client 가 됩니다.

Client 인 Replica MySQL 은 binary log 의 데이터를 Source MySQL 에게 요청하는 셈이죠.

 

binary log dump 과정에서 두개의 MySQL 은 네트워크적으로 연결됩니다.

그리고 각각 통신을 담당하는 I/O Thread 가 필요한데요.

Source MySQL 의 Thread 를 binary log dump thread,

Replica MySQL 의 Thread 를 Replica I/O Thread 라고 부릅니다.

 

binary log dump thread 는 Replica I/O Thread 로부터 요청받은 bin log 를 제공합니다.

이 과정에서 Replication Protocol 에 입각한 통신이 이뤄지는데,

Replica I/O Thread 는 binary log dump thread 에게 읽어들일 binlog file 이름과 position 정보를 요청합니다.

그리고 binary log dump thread 는 요청에 대한 binlog 데이터를 제공합니다.

 

 

<Replication Protocol 에 대한 공식문서>

https://dev.mysql.com/doc/dev/mysql-server/latest/page_protocol_com_binlog_dump.html

 

Replica I/O Thread **

Replica I/O Thread 는 Replica MySQL 에서 Replication 을 위해 필요한 Thread 중 하나입니다.

Replica I/O Thread 는 Source MySQL 로부터 제공받은 binary log 데이터를 Relay Log 라는 로그 파일에 저장합니다.

Relay Log 는 Replica MySQL 에서 Replication 을 위해 사용하는 binary log 라고 생각하면 됩니다.

 

SQL Thread **

 

SQL Thread 는 Replica MySQL 에서 Replication 을 위해 필요한 마지막 Thread 입니다.

SQL Thread 는 relay log 에 기록된 DML 과 DDL 을 실행하며,

Replication 을 실행하는 쿼리 실행 쓰레드입니다.