GTID (Golobal Transaction ID) 是对于一个已提交事务的唯一编号,并且是一个全局(主从复制)唯一的编号。
GTID 复制和传统复制的区别:在启动主从复制时,不需要指定 binlog 文件名和 postion 号,直接 auto 即可。MySQL 会自动读取最后一个 relay,获取到上次已经复制的 GTID 号,从此号码开始向后复制即可。在 MHA 高可用环境下,在主库无法 SSH 时,从库进行数据补偿更加便捷。eg:
change master to master_host='192.168.31.205' ,master_user='rep',master_password='Rep_123456',master_auto_position=1;
在 /etc/my.cnf 上额外增加下面配置参数
[mysqld]
gtid-mode=on # 启用gtid类型,否则就是普通的复制架构
enforce-gtid-consistency=true # 强制GTID的一致性
log-slave-updates=1 # slave更新是否记入日志
在主库创建了一个数据库,查看到 gtid 号
登录从库,查看现在执行到的 gtid 号
show binlog events in 'mysql-bin.000001';
总结
- 在主从复制环境中,主库发生过的事务,在全局都是由唯一GTID记录的,更方便Failover
- 从库 change master to 的时候不再需要 binlog 文件名和 position 号, 设置 MASTER_AUTO_POSITION=1 即可;
- 在复制过程中,从库不再依赖 master.info 文件,而是直接读取最后一个 relaylog 的 GTID 号
- mysqldump备份时,默认会将备份中包含的事务操作,以以下方式
SET @@GLOBAL.GTID_PURGED='8c49d7ec-7e78-11e8-9638-000c29ca725d:1';
告诉从库,我的备份中已经有以上事务,你就不用运行了,直接从下一个 GTID 开始请求 binlog 就行。
主从优化 -- 从库开启多线程MTS
基于组提交的并行复制(Enhanced Multi-threaded Slaves)worker线程并发执行 relay log 中主库提交的事务。
开启要求:
5.7以上的版本
必须开启GTID
binlog必须是row模式
# 在从库上添加配置 (/etc/my.cnf)
slave-parallel-type=LOGICAL_CLOCK
slave-parallel-workers=16 # cpu核心数作为标准
master_info_repository=TABLE
relay_log_info_repository=TABLE