mysql gtid 主从_基于GTID搭建主从MySQL

基于gtid搭建主从MySQL

一、GTID的使用

想让主从之间使用gtid的方式同步数据，需要我们在配置文件中开启mysql对gtid相关的配置信息

找到my.cnf ，在mysqld模块中加入如下的配置。(主库从库都这样)

# on表示开启，OFF表示关闭

gtid-mode = ON

# 下面的两个变量必须开启，否则MySQL拒绝启动

# 通常情况，从服务器从主服务器接收到的更新不记入它的二进制日志。该选项告诉从服务器将其SQL线程执行的更新记入到从服务器自己的二进制日志

log-slave-updates = 1

log-bin = MySQL-bin

# 必须开启，否则MySQL不启动，因为MySQL的SQL和gtid

# 许多MySQL的SQL和GTID是不兼容的。比如开启ROW 格式时，CREATE TABLE … SELECT

# 在binlog中会形成2个不同的事务，GTID无法唯一。

# 另外在事务中更新MyISAM表也是不允许的。

enforce_gtid_consistency = 1 #

log-bin-index = MySQL-bin.index

对主库来说依然需要创建一个用于同步数据的账号

mysql> grant replication slave on *.* to MySQLsync@"10.123.123.213" identified by "MySQLsync123";

Query OK, 0 rows affected, 1 warning (0.00 sec)

对从库中执行如下命令：即可完成主从同步

CHANGE MASTER TO

MASTER_HOST='10.123.123.123',

MASTER_USER='MySQLsync',

MASTER_PASSWORD='MySQLsync123',

MASTER_PORT=8882,

MASTER_AUTO_POSITION = 1;

这种自动找点对方式，相对于之前使用bin-log+position找点就显得极其方便了。

省去了手动查看master执行到那个binlog，以及binlog的position。

做了如上的配置后，还是可以继续使用fileName和position找点，但是不推荐这样做了，如果非要这样做，设置MASTER-AUTO-POSITION=0

假设我们想在现有的主从集群上新加一个从库，如果这个主库已经运行很久了，binlog肯定曾经被purge过，所以如果主库中原来的数据不重要，不介意主从数据不一致，在从库中执行：

reset master;

# 缺失的GTID集合设置为purged ，执行这个命令请确保从库：@@global.gtid_executed为空

set global gtid_purged = ‘主库中曾经purge过的gtid记录’

# 然后通过MASTER_AUTO_POSITION=1完成自动找点

如果介意主从数据强一致可以考虑使用可以热备份的工具从主库拷贝数据到从库，完成数据的同步再在从库执行如上set global gtid_purged = 'xxx'

热备份工具如：xtrabackup , 它可以拷贝物理文件和redolog来支持热备份

二、GTID的简介

GTID (global transcation identifier)

GTID是MySQL5.6版本中添加进来的新特性 ，通过GTID取代同步模式1中手动查找fileName和position， 实现了自动找点。

比如一条update有语句进入MySQL之后经历如下过程：

1. 写undolog

2. 写redolog(prepare)

3. 写binlog

4. 写redolog(commit)

MySQL5.6之后加入了GTID新特性后，update语句经历如下过程

1. 写undolog # 回滚

2. 写redolog(prepare)# 保证提交的不会丢失

3. 写一个特殊的Binlog Event，类型为GTID_Event，指定下一个事务的GTID

4. 写binlog # 主从同步事物使用

5. 写redolog(commit)

这个GTID的作用就是用于去唯一的标示一个事物的id。

主从之间，之所以能完成数据的同步，是因为从库会dump主库记录的binlog， 主库将自己成功执行过的事物都写在binlog用于给从库回放。当我们在mysql的配置文件中将上面的配置都打开时，主库在记录binlog的同时在binlog中会混杂着gtid的信息，这个gtid和当前事物唯一对应。

当从库向主库发送同步数据当请求时：bin-log和gtid都会传送到slave端，slave在回放日志同步数据时，同样会使用gtid写bin-log，这样主库和从库之间的数据，就通过GTID强制性的关联并且保持同步了。

下图中浅色的背景是一条完整的binlog，从binlog的记录中可以发现，gtid也写在binlog中，当前事物提交commit后，还会为下一个事物生成一个gtid待使用。