作者:俊达
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_mode
enforce_gtid_consistency=ON
gtid_mode=ON
log_bin=/data/mysql5.6/binlog/binlog
log_slave_updates=ON
binlog_format=ROW
server_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=ON
gtid_mode=ON
log_bin=/data/mysql5.6/binlog/binlog
log_slave_updates=ON
binlog_format=ROW
server_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-updates
2023-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