深入了解主从复制GTID(全局事务标识符)

1)什么是GTID

GTID(Global Transaction ID)是对于一个已提交事务的编号,并且是一个全局唯一的编号。GTID实际上是由UUID+TID组成的。其中UUID是一个MySQL实例的唯一标识,保存在mysql数据目录下的auto.cnf文件里。TID代表了该实例上已经提交的事务数量,并且随着事务提交单调递增。文章源自靠谱运维-https://www.ixdba.net/archives/1843

下面是一个GTID的具体形式:3E11FA47-71CA-11E1-9E33-C80AA9429562:23。文章源自靠谱运维-https://www.ixdba.net/archives/1843

2)GTID的作用

根据GTID可以知道事务最初是在哪个实例上提交的文章源自靠谱运维-https://www.ixdba.net/archives/1843

GTID的存在方便了Replication的Failover文章源自靠谱运维-https://www.ixdba.net/archives/1843

3)GTID比传统复制的优势

更简单的实现failover,不用以前那样在需要找log_file和log_Pos。文章源自靠谱运维-https://www.ixdba.net/archives/1843

更简单的搭建主从复制。文章源自靠谱运维-https://www.ixdba.net/archives/1843

比传统复制更加安全。文章源自靠谱运维-https://www.ixdba.net/archives/1843

GTID是连续没有空洞的,因此主从库出现数据冲突时,可以用添加空事物的方式进行跳过。文章源自靠谱运维-https://www.ixdba.net/archives/1843

4)GTID的工作原理:

master更新数据时,会在事务前产生GTID,一同记录到binlog日志中。文章源自靠谱运维-https://www.ixdba.net/archives/1843

slave端的i/o线程将变更的binlog,写入到本地的relay log中。文章源自靠谱运维-https://www.ixdba.net/archives/1843

sql线程从relay log中获取GTID,然后对比slave端的binlog是否有记录。文章源自靠谱运维-https://www.ixdba.net/archives/1843

如果有记录,说明该GTID的事务已经执行,slave会忽略。文章源自靠谱运维-https://www.ixdba.net/archives/1843

如果没有记录,slave就会从relay log中执行该GTID的事务,并记录到binlog。文章源自靠谱运维-https://www.ixdba.net/archives/1843

在解析过程中会判断是否有主键,如果没有就用二级索引,如果没有就用全部扫描。文章源自靠谱运维-https://www.ixdba.net/archives/1843

5)GTID常用参数注释:

GTID的参数注释:文章源自靠谱运维-https://www.ixdba.net/archives/1843

[master]>showglobal variables like '%gtid%';
  • enforce_gtid_consistency:开启gtid的一些安全限制(介意开启)。
  • gtid_executed:全局和seeeion级别都可以用。用来保存已经执行过的GTIDs。注意,showmaster status\G;输出结果中的Executed_Gtid_Set和gitd_executed一致。reset master时,此值会被清空。
  • gtid_owned:全局和session级别都可用,全局表示所有服务器拥有GTIDs,session级别表示当前client拥有所有GTIDs。(此功能用的少)
  • gtid_mode:是否开启GTID功能。
  • gtid_purged:全局参数,设置在binlog中,已经purged的GTIDs,并且purged掉的GTIDs会包含到gtid_executed中。注意,从而导致slave不会再去master请求这些GTIDs,并且Executed_Gtid_Set为空时,才可以设置此值。
  • gtid_next:这个时session级别的参数:

6)使用GTID配置主从复制

实际工作主要会在两种情况下配置:一是新搭建的服务器,直接配置启动就可以,二是已经在运行的服务器,这时候需要闭关master的写,保证所有slave端都已经和master端数据保持同步。然后即可按如下方法配置文章源自靠谱运维-https://www.ixdba.net/archives/1843

主服务器配置:文章源自靠谱运维-https://www.ixdba.net/archives/1843

停止mysql服务,修改/etc/my.cnf配置文件,主要配置以下几项:文章源自靠谱运维-https://www.ixdba.net/archives/1843

log-bin =mysql-bin
log_bin_index =mysql-bin.index
expire_logs_days = 30
binlog_format = ROW
log-slave-updates = true
sync-binlog = 1:
gtid-mode = on
enforce-gtid-consistency = true

启动数据库服务,查看相关信息文章源自靠谱运维-https://www.ixdba.net/archives/1843

使用如下命令查看GTID的相关参数:showglobal variables like '%gtid%';文章源自靠谱运维-https://www.ixdba.net/archives/1843

深入了解主从复制GTID(全局事务标识符)文章源自靠谱运维-https://www.ixdba.net/archives/1843

下图显示GTID是否正常使用:文章源自靠谱运维-https://www.ixdba.net/archives/1843

深入了解主从复制GTID(全局事务标识符)文章源自靠谱运维-https://www.ixdba.net/archives/1843

再次使用show global variables like '%gtid%';查看参数设置,出现如下结果。文章源自靠谱运维-https://www.ixdba.net/archives/1843

深入了解主从复制GTID(全局事务标识符)文章源自靠谱运维-https://www.ixdba.net/archives/1843

配置从服务器:文章源自靠谱运维-https://www.ixdba.net/archives/1843

停止mysql服务,修改/etc/my.cnf配置文件,主要配置以下几项:文章源自靠谱运维-https://www.ixdba.net/archives/1843

gtid-mode = on
enforce-gtid-consistency = true
server-id = 1
log-bin =mysql-bin
log_bin_index =mysql-bin.index
expire_logs_days = 30
binlog_format = ROW
sync-binlog = 1
relay-log = relay-log
relay-log-index = relay-log.index
log-slave-updates = true
master-info-repository = table
relay-log-info-repository = table
slave-parallel-workers = 1
relay_log_purge = 1
relay_log_recovery = 1
report-port = 3306
report-host = 192.168.10.72
skip-slave-start

启动数据库服务文章源自靠谱运维-https://www.ixdba.net/archives/1843

连接master:文章源自靠谱运维-https://www.ixdba.net/archives/1843

CHANGE MASTER TOMASTER_HOST='192.168.10.71',MASTER_PORT=3306,MASTER_USER='repl_user',MASTER_PASSWORD='123456', MASTER_AUTO_POSITION=1;

启动复制线程:文章源自靠谱运维-https://www.ixdba.net/archives/1843

start slave;

查看相关状态:文章源自靠谱运维-https://www.ixdba.net/archives/1843

slave上显示:文章源自靠谱运维-https://www.ixdba.net/archives/1843

mysql> show slave status\G;
*************************** 1. row***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 192.168.10.71
Master_User: repl_user
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: master-bin.000008
Read_Master_Log_Pos: 191
Relay_Log_File: relay-log.000005
Relay_Log_Pos: 363
Relay_Master_Log_File: master-bin.000008
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: 191
Relay_Log_Space: 530
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: 171
Master_UUID:0e9896a7-14f7-11e7-a0e6-000c2900551e
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 the slaveI/O thread to update it
Master_Retry_Count: 86400
Master_Bind:
Last_IO_Error_Timestamp:
Last_SQL_Error_Timestamp:
Master_SSL_Crl:
Master_SSL_Crlpath:
Retrieved_Gtid_Set:
Executed_Gtid_Set: 0e9896a7-14f7-11e7-a0e6-000c2900551e:1
Auto_Position: 1
1 row in set (0.00 sec)

在master显示:文章源自靠谱运维-https://www.ixdba.net/archives/1843

深入了解主从复制GTID(全局事务标识符)文章源自靠谱运维-https://www.ixdba.net/archives/1843

7)、修复GTID复制错误文章源自靠谱运维-https://www.ixdba.net/archives/1843

在基于GTID的复制拓扑中,要想修复Slave的SQL线程错误,过去的SQL_SLAVE_SKIP_COUNTER方式不再适用。需要通过设置gtid_next或gtid_purged完成,当然前提是已经确保主从数据一致,仅仅需要跳过复制错误让复制继续下去。其中gtid_next就是跳过某个执行事务,设置gtid_next的方法一次只能跳过一个事务,要批量的跳过事务可以通过设置gtid_purged完成。文章源自靠谱运维-https://www.ixdba.net/archives/1843

  • 本文由 发表于 2021年12月8日07:48:59
  • 转载请务必保留本文链接:https://www.ixdba.net/archives/1843
匿名

发表评论

匿名网友 填写信息

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen: