转载

MySQL主从复制集群—gtid实现详解

老哥唠叨

上一篇发了 MySQL 主从复制集群搭建流程，不过好像小伙伴们对这个文章并不感兴趣，但是老哥出于对技术的热爱，和对小伙伴们的负责，我还是要写主从复制另一种实现方式： GTID 。这些技术真的蛮重要的，希望你们能学习。

GTID 简介

从 MySQL 5.6.5 版本新增了一种主从复制方式： GTID ，其全称是 Global Transaction Identifier ，即全局事务标识。通过 GTID 保证每个主库提交的事务在集群中都有唯一的一个 事务ID 。强化了数据库主从的一致性和故障恢复数据的容错能力。在主库宕机发生主从切换的情况下。 GTID 方式可以让其他从库自动找到新主库复制的位置，而且 GTID 可以忽略已经执行过的事务，减少了数据发生错误的概率。

GTID 组成

GTID 是对一个已经提交事务的编号，并且是全局唯一的。 GTID 是由 UUID 和 TID 组成的。 UUID 是 MySQL 实例的唯一标识， TID 代表该实例上已经提交的事务数量，随着事务提交数量递增。

举个例子： 3E11FA47-71CA-11E1-9E33-C80AA9429562:23 ，冒号前面是 UUID ，后面是 TID 。

GTID 工作原理

主库 master 提交一个事务时会产生 GTID，并且记录在 binlog 日志中
从库 salve I/O 线程读取 master 的 binlog 日志文件，并存储在 slave 的 relay log 中。slave 将 master 的 GTID 这个值，设置到 gtid_next 中，即下一个要读取的 GTID 值。
slave 读取这个 gtid_next，然后对比 slave 自己的 binlog 日志中是否有这个 GTID
如果有这个记录，说明这个 GTID 的事务已经执行过了，可以忽略掉
如果没有这个记录，slave 就会执行该 GTID 事务，并记录到 slave 自己的 binlog 日志中。在读取执行事务前会先检查其他 session 持有该 GTID，确保不被重复执行。
在解析过程中会判断是否有主键，如果没有就用二级索引，如果没有就用全部扫描。

GTID实现

环境

这里我们准备两台机器，一主一从。

主（master）：192.168.216.111
从（salve）：192.168.216.222

master主库配置

在 [mysqld] 下配置，配置完需要重启

#GTID:
server_id=111  #服务器id，一般设置为机器 IP 地址后三位
gtid_mode=on  #开启gtid模式

#强制gtid一致性，开启后对于特定create table不被支持
enforce_gtid_consistency=on

#binlog
log_bin = 二进制日志文件存放路径
log-slave-updates=true

#强烈建议，其他格式可能造成数据不一致
binlog_format=row

#relay log
skip_slave_start=1
复制代码

slave从库配置

在 [mysqld] 下配置，配置完需要重启

#GTID:
gtid_mode=on #开启gtid模式
enforce_gtid_consistency=on

#服务器id，一般设置为机器 IP 地址后三位
server_id=222

#binlog
log-bin=slave-binlog
log-slave-updates=true

#强烈建议，其他格式可能造成数据不一致
binlog_format=row

#relay log
skip_slave_start=1
复制代码

检查GTID是否开启

show variables like '%gtid%';
复制代码

主库建立授权用户

# 建立授权用户
GRANT REPLICATION SLAVE ON *.* TO '用户名'@'从机IP' IDENTIFIED BY '密码';
# 刷新MySQL的系统权限相关表
FLUSH PRIVILEGES;
复制代码

salve连接到master

CHANGE MASTER TO  
MASTER_HOST='master的IP',    
MASTER_USER='用户名',    
MASTER_PASSWORD='密码',    
MASTER_PORT=端口号,    
# 1 代表采用GTID协议复制
# 0 代表采用老的binlog复制
MASTER_AUTO_POSITION = 1;
复制代码