MySQL GTID 를 사용한 Replication(복제) 설정

Last Updated on 3월 12, 2021 by 태랑(정현호)



1. GTID

GTID 는 Global Transaction IDentifier 약자로 MySQL 데이터베이스에서 커밋되는 각 트랜잭션과 함께 생성되고 트랜잭션에 연결되는 고유한 식별자입니다

이 식별자는 복제의 Master 서버 뿐만 아니라 복제 대상에 속한 Replica(slave) 서버에서 고유한 식별자 입니다

GTID 는 아래와 같이 구성되어 있습니다.
GTID = source_id:transaction_id

c3bae1f6-7a74-11eb-9bd7-020017084359:24
-> 24번째 트랜잭션을 의미


master 와 slave 간 복제 시작, 중지의 기준이 되었던 binlog 파일명과 pos 정보 대신 GTID 를 사용할 수 있으며 다음과 같은 특징을 가지게 됩니다.

 - CHANGE MASTER TO 의 MASTER_LOG_FILE, MASTER_LOG_POS 의 사용하지 않아도 됨
 - GTID 정보만으로 replication master - slave 간 일관성 확인이 쉽게 수행됨
 - slave에 반영된 gtid 트랜잭션이 mysql.gtid_executed 로 관리되기 때문에 중복 수행 안됨


트랜잭션이 커밋되면 GTID를 할당 받고 binlog 에 기록이 되게 됩니다. 할당된 GTID 는 gtid_executed system variable 과 mysql.gtid_executed 에 저장되게 됩니다

mysql> select @@global.gtid_executed;
+-------------------------------------------+
| @@global.gtid_executed                    |
+-------------------------------------------+
| c3bae1f6-7a74-11eb-9bd7-020017084359:24   |
+-------------------------------------------+

mysql> select * from mysql.gtid_executed;
+--------------------------------------+----------------+--------------+
| source_uuid                          | interval_start | interval_end |
+--------------------------------------+----------------+--------------+
| c3bae1f6-7a74-11eb-9bd7-020017084359 |              1 |           24 |
+--------------------------------------+----------------+--------------+




2. 파라미터 설정

gtid 를 사용하여 복제하기 위해서 gtid 관련된 파라미터를 사전에 설정 후 MySQL 서버의 재시작을 해야 합니다.
포스팅에서는 아래와 같이 설정 하였습니다(master /slave 모두 설정)

[root]# vi /etc/my.cnf

# master
[mysqld]
server-id=1
log-bin=binlog
gtid-mode=ON
enforce-gtid-consistency=ON
log_slave_updates=ON


# slave 
[mysqld]
server-id=2
log-bin=binlog
gtid-mode=ON
enforce-gtid-consistency=ON
log_slave_updates=ON


# 설정 후 재시작 
[root]# systemctl restart mysqld



# 재시작 후 조회
mysql> show variables like '%gtid_mode%';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| gtid_mode     | ON    |
+---------------+-------+



[참고] 포스팅에서는 gtid 관련된 내용과 편의성을 위해서 기본 async 으로 진행 하였습니다 Seme-Sync 방식 등에 대해서는 아래 포스팅을 참조하시면 됩니다.





3. 유저 생성 및 mysqldump 수행

먼저 복제 전용 유저를 생성을 하도록 하겠습니다.

3-1 replication 전용 유저 생성

mysql> create user 'repl_user'@'%' identified by 'Repl_user1234!@#$';
mysql> grant replication slave,replication client on *.* to 'repl_user'@'%';
mysql> flush privileges;

*  유저명 과 패스워드는 예시 입니다.


3-2 mysqldump 수행

mysql> mysqldump -u아이디 -p패스워드 -v --databases testdb \
 --quick --single-transaction --routines --set-gtid-purged=OFF \
 --triggers --extended-insert --master-data=2 \
 | gzip > /root/db_backup/testdb.sql.gz

or 

## login-path 이용시
mysql> mysqldump --login-path=dba -v --databases testdb \
 --quick --single-transaction --routines --set-gtid-purged=OFF \
 --triggers --extended-insert --master-data=2 \
 | gzip > /root/db_backup/testdb.sql.gz


* 포스팅에서는 1개의 데이터베이스만을 dump/load 하였습니다. 

[참조] --login-path 에 관해서는 아래 포스팅을 참조하시면 됩니다.



3-3 다른 서버로 전송 및 Data Load

# Master 서버 : 파일 전송
[root]# rsync -avzr --progress testdb.sql.gz root@다른서버:~/


# Slave 서버 : 압축 해제 및 데이터 Load
[root]#  gunzip testdb.sql.gz

mysql> source testdb.sql




4. Replication 설정

slave 서버에서 아래와 같이 change master 를 수행하여 복제를 설정 합니다.

# 복제 설정
mysql> CHANGE MASTER TO MASTER_HOST="wmp1",
MASTER_USER='repl_user',MASTER_PASSWORD='Repl_user1234!@#$',
MASTER_AUTO_POSITION=1;

# 복제 시작 및 확인
mysql> start slave;
mysql> show slave status\G



• 복제 수행 여부 간단 확인

# Master Server 
mysql> use testdb;
Database changed

mysql> create table test_1 (
    no int(10) auto_increment , 
    col1 varchar(10), 
    primary key(no));
Query OK, 0 rows affected (0.01 sec)

mysql> insert into test_1 values(1,'a');
Query OK, 1 row affected (0.00 sec)

mysql> commit;
Query OK, 0 rows affected (0.00 sec)

mysql> select * from test_1;
+----+------+
| no | col1 |
+----+------+
|  1 | a    |
+----+------+
1 row in set (0.00 sec)



# Slave Server
mysql> use testdb;
Database changed

select * from test_1;
+----+------+
| no | col1 |
+----+------+
|  1 | a    |
+----+------+
1 row in set (0.00 sec)




5. conclusion

GTID 를 사용한 Replication 에는 몇가지 제약 사항이 있습니다 자세한 사항은 아래 도큐먼트를 확인 해보시면 되며 대표적으로 미지원 되는 기능이 CTAS 입니다.

5.7 버전 doc/replication-gtids-restrictions [Link]
8.0 버전 doc/replication-gtids-restrictions [Link]

mysql> create table tb_test_ctas as select * from tb_test;
ERROR 1786 (HY000): Statement violates GTID consistency: CREATE TABLE ... SELECT.



GTID 환경에서의 제약사항은 아래와 같이 like 로 생성 후 insert select 는 가능 합니다.

mysql> create table tb_test_like like tb_test;
Query OK, 0 rows affected (0.01 sec)

mysql> insert into tb_test_like 
    -> select * from tb_test;
Query OK, 8130 rows affected (0.32 sec)
Records: 8130  Duplicates: 0  Warnings: 0


제약 사항은 버전의 변경에 따라 변경이 되며, MySQL 8.0.21 에서 부터는 CTAS 사용 가능 하도록 개선 되었습니다.
This restriction is lifted in MySQL 8.0.21 on storage engines that support atomic DDL. In this case, CREATE TABLE … SELECT is recorded in the binary log as one transaction


GTID 의 사용이 확대되는 추세이며, Cloud의 완전관리형 Database(PaaS) 인 RDS 나 MDS 와 같은 서비스에도 GTID 를 통해서 IDC 나 다른 클라우드내 MySQL 간의 Outbound Replication 을 구성할 수 있기도 합니다.
8.0.21 에서 부터는 CTAS 에 대한 제약도 개선 되었기 때문에 사용을 고민해보는 것도 좋을 것 같습니다.

[참고] GTID 사용 환경에서 Replica(Slave)에서 에러가 발생되어 Skip 이 필요한 경우 조치는 아래 포스팅을 참조하시면 됩니다.



Ref link
dev.mysql.com/replication-gtids-lifecycle [Link]
dev.mysql.com/replication-msr [Link]
5.7 dev.mysql.com/replication-gtids-restrictions [Link]
8.0 dev.mysql.com/replication-gtids-restrictions [Link]



관련 된 다른 글

 

 

 

 

 

 

 

답글 남기기