作者：俊达
MySQL从5.6版本开始反对GTID复制。开启GTID之后，主库上执行的每一个事务都有一个全局惟一的ID。GTID由两局部组成：server_uuid和事务序列号。初始化数据库时，会生成一个全局惟一的server_uuid，server_uuid保留在datadir下的auto.cnf中：

# cat auto.cnf[auto]server-uuid=e7ce5684-09b8-11ee-9dd0-fa8338b09400

如果删除auto.cnf，重启实例时会从新生成。事务序列号在事务提交时按程序生成。

GTID事务复制到备库时，GTID放弃不变。开启GTID有很多长处：

1、MySQL会记录执行过的GTID事务，这样就能够防止反复执行同一个事务。如果没有开启GTID，change master时如果指定的位点不对，可能会反复执行事务，引起主备数据不统一或复制中断。

2、change master时反对主动定位，mysql会依据以后实例曾经执行过的GTID事务，主动判断须要同步哪些binlog。

1、主库开启GTID

除了惯例的参数，主库须要配置

enforce_gtid_consistency和gtid_modeenforce_gtid_consistency=ONgtid_mode=ONlog_bin=/data/mysql5.6/binlog/binloglog_slave_updates=ONbinlog_format=ROWserver_id=234

2、主库创立复制账号

在进行主库和备库之间的复制前，须要在主库上创立一个专用于复制的账号，并授予相应的权限。以下是创立复制账号的步骤：

-- 创立复制账号CREATE USER 'rep'@'%' IDENTIFIED BY 'rep123';-- 授予复制账号必要的权限GRANT REPLICATION SLAVE ON *.* TO 'rep'@'%';

创立完复制账号后，备库能够应用这个账号连贯到主库，并通过复制账号进行数据同步。在备库上配置复制时，将会应用这个账号的凭证信息。

3、备库配置

5.6版本开启GTID时，备库也必须开启log-bin和log-slave-updates，否则无奈启动实例。

enforce_gtid_consistency=ONgtid_mode=ONlog_bin=/data/mysql5.6/binlog/binloglog_slave_updates=ONbinlog_format=ROWserver_id=236

5.6版本开启GTID，不设置log-bin和log-slave-updates，实例无奈启动：

2023-06-14 14:56:35 23275 [ERROR] --gtid-mode=ON or UPGRADE_STEP_1 or UPGRADE_STEP_2 requires --log-bin and --log-slave-updates2023-06-14 14:56:35 23275 [ERROR] Aborting

从5.7版本开始，备库不开启binlog和log-slave-updates也能够应用GTID。

4、备库初始化

这一步和非GTID的步骤根本一样。不过开启GTID后，通常须要记录GTID_PURGED，作为复制的终点。

/opt/mysql5.7/bin/mysqldump -uroot -h127.0.0.1 -P3357 -pabc123 --all-databases \ --master-data=2 --routines --flush-privileges --triggers --events > /tmp/mysql57_dump.sql

--gtid-mode=auto：如果数据库开启了GTID，则备份文件中会退出set global GTID_PURGED=xxx;

5、备库创立复制通道

change master to master_host='172.16.121.234',master_port=3356,\master_user='rep',master_password='rep123', master_auto_position=1;

开启GTID之后，能够在change master时指定master_auto_position=1，启用主动定位。这样就不须要指定具体的binlog位点。slave会依据gtid_executed主动计算须要同步主库的哪些binlog。

更多技术信息请查看云掣官网https://yunche.pro/?t=yrgw