MySQL GTID 복제 환경에서 Reset Master/Reset Slave 명령어

글을 작성하기 전에

해당 포스팅은 복제 환경에서 초기 환경 구성시 자주 사용되는 Reset Master / Reset Slave 명령어에 대해 정리는 포스팅입니다. 그중 GTID 기반 Replication시 명령어를 수행하면 변경되는 내용에 중점을 둘 예정입니다. GTID 개념에 대해서는 아래 포스팅을 참고하면 좋습니다.

2022.12.22 - [MySQL & MariaDB] - MySQL GTID Replication 실습

MySQL GTID Replication 환경에서 Reset Master/Reset Slave 명령어

복제 환경에서 쉽게 상태를 확인할 수 있는 명령어는 Slave에서 수행하는  show slave status; 명령어이다.

mysql> show slave status\G show master status; *************************** 1. row ***************************                Slave_IO_State: Waiting for source to send event                   Master_Host: 10.213.211.170                   Master_User: replication_user                   Master_Port: 3306                 Connect_Retry: 60               Master_Log_File: binlog.000001           Read_Master_Log_Pos: 2907                Relay_Log_File: ip-10-213-212-194-relay-bin.000003                 Relay_Log_Pos: 3117         Relay_Master_Log_File: binlog.000001              Slave_IO_Running: Yes             Slave_SQL_Running: Yes               Replicate_Do_DB:            Replicate_Ignore_DB:             Replicate_Do_Table:         Replicate_Ignore_Table:        Replicate_Wild_Do_Table:    Replicate_Wild_Ignore_Table:                     Last_Errno: 0                    Last_Error:                   Skip_Counter: 0           Exec_Master_Log_Pos: 2907               Relay_Log_Space: 3519               Until_Condition: None                Until_Log_File:                  Until_Log_Pos: 0            Master_SSL_Allowed: No            Master_SSL_CA_File:             Master_SSL_CA_Path:                Master_SSL_Cert:              Master_SSL_Cipher:                 Master_SSL_Key:          Seconds_Behind_Master: 0 Master_SSL_Verify_Server_Cert: No                 Last_IO_Errno: 0                 Last_IO_Error:                 Last_SQL_Errno: 0                Last_SQL_Error:    Replicate_Ignore_Server_Ids:               Master_Server_Id: 2                   Master_UUID: 059417b0-6f07-11ed-9907-02b33e34566e              Master_Info_File: mysql.slave_master_info                     SQL_Delay: 0           SQL_Remaining_Delay: NULL       Slave_SQL_Running_State: Replica has read all relay log; waiting for more updates            Master_Retry_Count: 86400                   Master_Bind:        Last_IO_Error_Timestamp:       Last_SQL_Error_Timestamp:                 Master_SSL_Crl:             Master_SSL_Crlpath:             Retrieved_Gtid_Set: 059417b0-6f07-11ed-9907-02b33e34566e:1-10             Executed_Gtid_Set: 059417b0-6f07-11ed-9907-02b33e34566e:1-10                 Auto_Position: 1          Replicate_Rewrite_DB:                   Channel_Name:             Master_TLS_Version:         Master_public_key_path:          Get_master_public_key: 0             Network_Namespace:  1 row in set, 1 warning (0.00 sec) +---------------+----------+--------------+------------------+-------------------------------------------+ | File          | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set                         | +---------------+----------+--------------+------------------+-------------------------------------------+ | binlog.000001 |     2927 |              |                  | 059417b0-6f07-11ed-9907-02b33e34566e:1-10 | +---------------+----------+--------------+------------------+-------------------------------------------+ 1 row in set (0.00 sec)

 

IO 쓰레드 정상여부 : Slave_IO_Running, SQL 쓰레드 정상여부 : Slave_SQL_Running

반영된 Binlog Position :  Read_Master_Log_Pos, Exec_Master_Log_Pos 값

 

Binlog 기반 Replication 시 위의 파라미터들을 확인하여 정상여부를 주로 판단 하지만, GTID Replication 시 GTID 관련 정보를 추가 확인해야한다.

 

Retrieved_Gtid_set : Slave 입장에서 Master에게 전달받은 GTID Set, 만약 Master라면 해당 값이 비어있음

Executed_Gtid_set :  Master 입장에서는 자신이 수행한 GTID SET을 의미하며, Slave 입장에서는 log-slave-updates 가 on일 시  Master의 트랜잭션을 전달받아 Binary log에 작성한 GTID SET

 

Retrieved_Gtid_set 과 Executed_Gtid_set에 대해서 구별하여 이해하여야 한다.

 

Reset Master

GTID가 사용 중인 서버의 경우 RESET MASTER를 실행하면 GTID 실행 기록이 재설정됩니다. gtid_purged 시스템 변수의 값은 빈 문자열('')로 설정되고, gtid_executed 시스템 변수의 글로벌 값(세션 값은 아님)은 빈 문자열로 설정되며, mysql.gtid_executed 테이블은 지워집니다. GTID 지원 서버에 바이너리 로깅이 활성화된 경우 RESET MASTER는 위에서 설명한 대로 바이너리 로그도 재설정합니다. RESET MASTER는 GTID 지원 서버가 바이너리 로깅이 비활성화된 복제본인 경우에도 GTID 실행 기록을 재설정하는 방법입니다. RESET SLAVE는 GTID 실행 이력에 영향을 미치지 않습니다.
(해당 구문 상세 설명 https://dev.mysql.com/doc/refman/8.0/en/reset-master.html 참조)

 

-> GTID Replication 구성 시 Reset Master 를 수행하게 되면 gtid_executed값이 빈 문자열로 설정되고 Binary File을 전부 Purge하고 파일을 초기화함. (+ Executed_Gtid_set도 동일하게 빈문자로 설정됨) 

 

Reset Replica (Slave )

RESET SLAVE는 슬레이브가 마스터의 바이너리 로그에서 복제 위치를 제거합니다. 이 명령문은 복제를 새로 시작하는 데 사용됩니다. 복제 메타데이터 저장소를 지우고 모든 릴레이 로그 파일을 삭제하고 새 릴레이 로그 파일을 시작합니다. 또한 MASTER_DELAY 옵션에서 CHANGE MASTER TO로 지정된 복제 지연을 0으로 재설정합니다.

 

GTID가 사용 중인 서버(gtid_mode가 ON)의 경우 RESET REPLICA를 실행해도 GTID 실행 기록에 영향을 미치지 않습니다. 명령문은 gtid_executed 또는 gtid_purged 또는 mysql.gtid_executed 테이블의 값을 변경하지 않습니다. GTID 실행 기록을 재설정해야 하는 경우 GTID 사용 서버가 바이너리 로깅이 비활성화된 복제본인 경우에도 RESET MASTER를 사용하십시오.

(해당 구문 상세 설명 https://dev.mysql.com/doc/refman/8.0/en/reset-replica.html 참조)

 

-> GTID Replication 구성시 Reset Slave 를 수행하게 되면 현재까지 반영한 gtid_executed(Executed_Gtid_set) 값을 변경하지 않지만 Retrieved_Gtid_set 값을 빈 문자열로 설정함

 

결론

복제 환경 초기 구성시 사용하는 Reset Master / Reset Slave 명령어에 대해 이해하고 GTID Replication 시 binlog 기반 복제 방식과 명령어 차이에 대해 이해해야함.

만약 불필요하게 명령어를 수행했다면 GTID_Purged(GTID_Executed - read only) 명령어를 통해 적절한  GTID를 셋팅해줘야함 

 

아래 포스팅에서 Reset Master 수행 이후 발생 할 수 있는 케이스에 대해 분류하였음.

 

2022.12.27 - [MySQL & MariaDB] - MySQL GTID 복제 환경에서 Reset Master 수행 시 발생 장애 케이스

 

출처

글 작성 간 참고한 SlideShare https://www.slideshare.net/LeeIGoo/mysql-gtid