MySQL主从复制之GTID模式介绍
原创MySQL主从复制之GTID模式介绍
原创
> * GreatSQL社区原创内容未经授权不得随意使用，转载请联系小编并注明来源。
GTID概述
MySQL5.6 在原有主从复制的基础上增加了一个新的复制方式，即基于GTID的复制方式，它由UUID和事务ID两个部分组成，具有如下特点。
- GTID事务是全局唯一性的，并且一个事务对应一个GTID值。
- 一个GTID值在同一个MySQL实例上只会执行一次。
GTID相较与传统复制的优势
- 主从搭建更加简便，不用手动特地指定position位置。
- 复制集群内有一个统一的标识，识别、管理上更方便。
- 故障转移更容易，不用像传统复制那样需要找 log_file 和 log_Pos的位置。
- 通常情况下GTID是连续没有空洞的，更能保证数据的一致性，零丢失。
- 相对于ROW复制模式，数据安全性更高，切换更简单。
- 比传统的复制更加安全，一个GTID在一个MySQL实例上只会执行一次，避免重复执行导致数据混乱或者主从不一致。
GTID自身存在哪些限制
- 在一个复制组中，必须都要开启GTID。
- MySQL5.6开启GTID需要重启。
- 不支持sql_slave_skip_counte操作，传统复制可以使用这个命令跳过事务。
- 不允许在一个SQL同时更新一个事务引擎和非事务引擎的表，如InnoDB和MyISAM。
- 对于create temporary table 和drop temporary table语句不支持。
- 不支持create table … select 语句复制。
GTID工作原理简单介绍
- master节点在更新数据的时候，会在事务前产生GTID信息，一同记录到binlog日志中。
- slave节点的io线程将binlog写入到本地relay log中。
- 然后SQL线程从relay log中读取GTID，设置gtid_next的值为该gtid，然后对比slave端的binlog是否有记录。
- 如果有记录的话，说明该GTID的事务已经运行，slave会忽略。
- 如果没有记录的话，slave就会执行该GTID对应的事务，并记录到binlog中。
如何开启GTID复制
- 除传统复制需要开启的binlog相关参数之外，GTID同步需额外开启如下参数设置，注意主从节点需要同步开启。
gtid_mode=on # 开启GTID
enforce-gtid-consistency=on # 需要同步设置该参数
log-slave-updates=1 # 5.6 版本需要开启该参数查看GTID相关参数
[root@GreatSQL][(none)]>show variables like '%gtid%';
+----------------------------------+-------------------------------------------------------------------------------------+
| Variable_name | Value |
+----------------------------------+-------------------------------------------------------------------------------------+
| binlog_gtid_simple_recovery | ON |
| enforce_gtid_consistency | ON |
| gtid_executed | 613743f5-8b1c-11ec-9922-00155dcff911:1-14 |
| gtid_executed_compression_period | 0 |
| gtid_mode | ON |
| gtid_next | AUTOMATIC |
| gtid_owned | |
| gtid_purged | |
| session_track_gtids | OFF |
+----------------------------------+-------------------------------------------------------------------------------------+
9 rows in set (0.00 sec)- 参数简要说明
参数名 | 含义介绍 |
|---|---|
binlog_gtid_simple_recovery | 该参数是控制当MySQL服务重启或启动时候自动寻找GTIDs的值。 |
enforce_gtid_consistency | 该参数是强制要求只允许复制事务安全的事务，请看上面步骤的具体限制。 |
gtid_executed | 已经执行过的GTID信息。 |
gtid_executed_compression_period | 启用GTID时，服务器会定期在mysql.gtid_executed表上执行压缩。通过设置gtid_executed_compression_period系统变量，可以控制压缩表之前允许的事务数，从而控制压缩率。设置为0时，则不进行压缩。 |
gtid_mode | 是否开启GTID模式 |
gtid_next | 表示下一个要执行的GTID信息 |
gtid_owned | 该参数包含全局和session，全局表示所有服务器拥有GTIDs，session级别表示当前client拥有的所有GTIDs。 |
gtid_purged | 已经purge掉的GTIDs，purged掉的GTIDs会包含到gtid_executed中。 |
session_track_gtids | 该参数是控制用于捕获的GTIDs和在OK PACKE返回的跟踪器。 |
GTID与传统模式建立复制时候语句的不同点
# 传统复制
change master to master_host="127.0.0.1",master_port=3310,MASTER_USER='sync',MASTER_PASSWORD='GreatSQL',MASTER_LOG_FILE='log-bin.000005', MASTER_LOG_POS=4111;
# GTID复制
change master to master_host="127.0.0.1",master_port=3310,MASTER_USER='sync',MASTER_PASSWORD='GreatSQL',MASTER_AUTO_POSITION=1GTID同步在建立复制的时候，将传统复制由人为指定binlog的pos位点改为了MASTER_AUTO_POSITION=1自动获取binlog的pos位点。
GTID同步状态简单解析
除了传统的查看binlog和pos值之外，GTID模式可以更直观的查看某个事务执行的情况。
[root@GreatSQL][(none)]>show slave status\G;
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 192.168.6.215
Master_User: sync
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: binlog.000001
Read_Master_Log_Pos: 2425
Relay_Log_File: mgr2-relay-bin.000002
Relay_Log_Pos: 2634
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: 2425
Relay_Log_Space: 2842
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: 2153306
Master_UUID: 613743f5-8b1c-11ec-9922-00155dcff911
Master_Info_File: mysql.slave_master_info
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State: Slave 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: 613743f5-8b1c-11ec-9922-00155dcff911:1-10
Executed_Gtid_Set: 613743f5-8b1c-11ec-9922-00155dcff911:1-10,
652ade08-8b1c-11ec-9f62-00155dcff90a:1-2
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.01 sec)
ERROR:
No query specified- GTID相关键参数说明
参数名 | 含义介绍 |
|---|---|
Retrieved_Gtid_Set | Slave节点已经接收到的Master节点的GTIDs |
Executed_Gtid_Set | Slave节点已经执行的GTIDs |
Auto_Position | 自动获取position位置，显示为1 |
总结
- 篇幅所限暂时写这么多，下周会继续出关于主从复制相关的内容，欢迎追更，另外受限于个人能力和经验，内容难免错漏，若有错误欢迎评论区指出更正。
关于 GreatSQL
GreatSQL是由万里数据库维护的MySQL分支，专注于提升MGR可靠性及性能，支持InnoDB并行查询特性，是适用于金融级应用的MySQL分支版本。
原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。
如有侵权，请联系 cloudcommunity@tencent.com 删除。
原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。
如有侵权，请联系 cloudcommunity@tencent.com 删除。