MaxScale, GTID로 데이터동기화 추적

Jeonghak Cho·2024년 12월 8일
0

MaxScale

목록 보기
7/8

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만 초기화되었으므로 정상이다.

0개의 댓글