GTID(global transaction identifier) 는 원 서버로 부터 커밋된 개별 트랜잭션에 대한 유일한 식별자로 복제가 공유되는 데이터베이스 클러스터 내에서 유일성이 보장된다. 트랜잭션이 커밋되면 GTID를 부여받고 binlog파일에 기록이된다. GTID 포맷은 server-id:transaction-id 이다. Maridb와 Mysql의 GTID는 호환이 되지 않으므로 Master/Slave관계로 엮을 수 없다.
Gtid_IO_Pos 의 값을 통해 Master와 Slave간의 복제 데이터 간의 이격 정도를 파악할 수 있다. Slave 에서 slave 상태를 확인하면 Gtid_IO_Pos이 0-3000-1 값으로 초기화 되어 있다.
MariaDB [(none)]> show slave status\G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: mariadb-0.mariadb.default.svc.cluster.local
Master_User: repl
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mariadb-bin.000001
Read_Master_Log_Pos: 447
Relay_Log_File: mariadb-relay-bin.000002
Relay_Log_Pos: 791
Relay_Master_Log_File: mariadb-bin.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: 447
Relay_Log_Space: 1102
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: Yes
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: Yes
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Master_Server_Id: 3000
Master_SSL_Crl:
Master_SSL_Crlpath:
Using_Gtid: Slave_Pos
Gtid_IO_Pos: 0-3000-1
Replicate_Do_Domain_Ids:
Replicate_Ignore_Domain_Ids:
Parallel_Mode: optimistic
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates
Slave_DDL_Groups: 5
Slave_Non_Transactional_Groups: 0
Slave_Transactional_Groups: 2
Replicate_Rewrite_DB:
1 row in set (0.000 sec)
MaxScale에서 확인할 경우 GUI 덕에 멱확히 Maser, Slave 간 복제 상태를 확인할 수 있다.
# 0-3000-2
CREATE DATABASE mdb;
# 0-3000-3
CREATE TABLE IF NOT EXISTS mdb.`tx_log` (
`tx_id` int(11) NOT NULL AUTO_INCREMENT,
`tx_no` int(11) NOT NULL,
`host_nm` varchar(100) NOT NULL,
`remark` text NULL,
`create_ts` timestamp NOT NULL,
PRIMARY KEY (`tx_id`)
)
# 0-3000-4
INSERT INTO mdb.tx_log (tx_no, host_nm,remark,create_ts)
VALUES (
1,
(SELECT @@hostname),
'',
now()
)
# 0-3000-1 (변화 없음)
SELECT * FROM mdb.tx_log;
이 상태에서 데이터베이스 생성, 테이블 생성, 데이터 삽입, 데이터 조회를 했을 경우 0-3000-4 로 조회를 제외한 트랜잭션 3건에 대한 수가 증가됨을 확인할 수 있다.
이 상태에서 slave 테이블에 직접 데이터를 집어넣을 경우 Slave 가 Master보다 GTIP Posion이 앞서 나가게 된다.
이어 Master에 데이터를 한건 더 추가하면, 데이터 동기화에 문제를 일으키며 Slave에 동기화 오류가 발생한다.
Master는 정상적으로 운영이 되었으나 Slave 중 하나에서 데이터 동기화에 지장을 주었다. 문제해결은 Master의 데이터로 Slave의 데이터를 초기화하는 것이다. MaxScale의 Reset Replication 기능을 이용한다.
Gtid_IO_Pos이 0-3000-1 값으로 다시 초기화되었다. 수행된 트랜잭션은 유지되고 Position만 초기화되었으므로 정상이다.