mysql 5.6 gtid 主从_Mysql5.6.21-GTID主从复制

什么是GTID：GTID(global transaction id)是对于一个已提交事务的编号，并且是一个全局唯一编号。

组成部分： UUID+TID

什么是UUID：Mysql实例的唯一标识。

什么是TID：TID代表了该实例上已经提交的事务数量，随着事务提交单调递增。

例子：6dec6fd5-eb1f-12e4-6532-000c29e336f3:20

GTID功能目的：

1：根据GTID可以知道事务最初是在哪个实例上提交的。

2：GTID的存在方便了复制的故障转移。

在5.6版本前，Replication的Failover操作过程。

GTID搭建

实验环境：3台服务器，A，B，C

一：A服务器:192.168.112.131

1：添加复制账号.

sql>GRANT REPLICATION SLAVE ON *.* TO ‘ruser’@’192.168.112.%’ IDENTIFIED BY ‘rpass’;

vim /data/mysqldata/3306/my.cnf

—————————————

server-id=1

log-slave-updates=true

gtid-mode=on

enforce-gtid-consistency=true

master-info-repository=TABLE

relay-log-info-repository=TABLE

sync-master-info=1

slave-parallel-workers=3

binlog-checksum=CRC32

master-verify-checksum=1

slave-sql-verify-checksum=1

binlog-rows-query-log-events=1

report-host=192.168.112.131

—————————————-

3：重启动Mysql服务

二：B服务器：192.168.112.132

1：配置文件添加以下信息，启用GTID模式。

vim /data/mysqldata/3306/my.cnfserver-id=10

log-slave-updates=true

gtid-mode=on

enforce-gtid-consistency=true

master-info-repository=TABLE

relay-log-info-repository=TABLE

sync-master-info=1

slave-parallel-workers=3

binlog-checksum=CRC32

master-verify-checksum=1

slave-sql-verify-checksum=1

binlog-rows-query-log-events=1

report-host=192.168.112.132

2：重启动Mysql服务

3：连接Mysql，建立主从关系。

sql>change master to master_host=’192.168.112.131′, master_user=’ruser’,master_password=’rpass’,master_auto_position=1;

sql>start slave;

sql>show slave status/G

4：查看slvae状态，获取关键参数值：Slave_IO_Running: YesSlave_SQL_Running: Yes

三：测试主从同步

1：A主数据库：

sql> create database testhuang;

2：B从数据库：

sql> show databases;

+———————–+| Database         |+———————–+| information_schema   || mysql          || performance_schema  || test            || testhuang         |+———————–+5 rows in set (0.00 sec)

3：B从数据库GTID执行状态

sql> show slave status/GRetrieved_Gtid_Set: 7edc6fd5-e1bf-11e4-8842-000c29e512d6:1Executed_Gtid_Set: 7edc6fd5-e1bf-11e4-8842-000c29e512d6:1

四：模拟binlog日志文件过期

模拟master-slave运行多时，master服务器的部分binlog因为expire_logs_days过期而被删除，此时需要添加多一台slave数据库。

A：192.168.112.131

B：192.168.112.132

服务器A：

1：查看当前主mysql数据库binlog日志文件，以及GTID。

sql>show master status;

sql>flush logs;

650) this.width=650;” src=”https://static.www.xigua.ink/wp-content/uploads/2016/07/20160716_578a512c100e6.jpg” title=”05.png” alt=”Mysql5.6.21-GTID主从复制” />

3：查看binlog日志位置，GTID位置。

sql>purge binary logs to ‘mysql-bin.000006’;

5：可以通过gitd_purge状态参数看到，GTID被清除的事务序号1-5。

sql>show global variables like ‘%gtid%’;

650) this.width=650;” src=”https://static.www.xigua.ink/wp-content/uploads/2016/07/20160716_578a512fb6880.jpg” title=”07.png” alt=”Mysql5.6.21-GTID主从复制” />

在数据库B-slave中，是可以发现t1-t6表的存在，因为已经同步过去了。我们再新增加slave-C的时候，就会发现C无法读取binlog日志而报错。可以通过跳过的方式解决。这样的话就会造成数据库binlog不存在的数据丢失，这个也没办法修复的。因为主从原理就是这样，只能是通过备份/还原的方式去重建。

五：GTID-跳过被清除的事务。

A：192.168.112.131

B：192.168.112.132

C：192.168.112.129

安装mysql参考之前的文章，数据库C添加GTID重要参数。重启动mysql，连接主库-A。

1：修改配置文件，添加以下内容。

vim /data/mysqldata/3306/my.cnfserver-id=12

log-slave-updates=true

gtid-mode=on

enforce-gtid-consistency=true

master-info-repository=TABLE

relay-log-info-repository=TABLE

sync-master-info=1

slave-parallel-workers=3

binlog-checksum=CRC32

master-verify-checksum=1

slave-sql-verify-checksum=1

binlog-rows-query-log-events=1

report-host=192.168.112.129

2：重启动mysql服务

3：连接主数据库，知道GTID的好处了吧。

sql>change master to master_host=’192.168.112.131′, master_user=’ruser’,master_password=’rpass’,master_auto_position=1;

sql>start slave;

sql>show slave status/G;

观察报错字段：Slave_IO_Running: No

Slave_SQL_Running: Yes

Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: ‘The slave is connecting using CHANGE MASTER TO MASTER_AUTO_POSITION = 1, but the master has

purged binary logs containing GTIDs that the slave requires.’

IO错误：读取主的二进制日志致命错误1236，备库请求的GTID的事务内容被清除。

4：跳过被清除的GTID事务。

刚才我们再主库上通过gtid_pirged状态参数查看到1-5的二进制日志文件已经丢失。那么我们跳过该事务。

sql>stop slave;

sql>reset master;

sql>set global gtid_purged = ‘7edc6fd5-e1bf-11e4-8842-000c29e512d6:1-5’;

sql>start slave

不知道我们是否发现，虽然跳过了1-5的事务，但是实际testhuang数据库还是没有创建的，如果跳过的该事务，肯定还会报错。报错没有找到testhuang数据库。

查看slave状态参数：sql>showslave status/GSlave_IO_Running: Yes

Slave_SQL_Running: No

Last_SQL_Error: Worker 2 failed executing transaction ” at master log mysql-bin.000006, end_log_pos 346; Error ‘Unknown database ‘testhuang” on query. Default database: ‘testhuang’. Query: ‘create table t5(id int)’

Retrieved_Gtid_Set: 7edc6fd5-e1bf-11e4-8842-000c29e512d6:6-7

Executed_Gtid_Set: 7edc6fd5-e1bf-11e4-8842-000c29e512d6:1-5

可以看到，IO线程正常了，但是sql线程异常，确实提示是没有找到testhuang数据库。

在看看后面两个参数，先解释一下：

Retrieved_Gtid_Set：记录了relay日志从Master获取了binlog日志的位置,没错吧，只能拿到事务6-7的日志了。

Executed_Gtid_Set：记录本机执行的binlog日志位置(如果是从机，包括Master的binlog日志位置和slave本身的binlog日志位置)可以从Last_SQL_Error看到创建t5失败。所以这里还是执行1-5，等于没执行。。

5：手动建立testhuang数据库，重新执行跳过事务。

sql>create database testhuang;

sql>stop slave;

sql>reset master;

sql>set global gtid_purged = ‘7edc6fd5-e1bf-11e4-8842-000c29e512d6:1-5’;

sql>start slave

下图是我拼起来的，观察几个重要的参数就可以了

sql>show slave status/G

六：GTID-完整Slave创建。

A：192.168.112.131

B：192.168.112.132

C：192.168.112.129

还是拿服务器C来做完全恢复，来个最干净的环境，把上面的数据库初始化。

前面说过日志文件丢失了，就没办法做恢复了，我们可以把数据备份出来，然后导入到C服务器上，再进行主从数据同步。考虑到A是主库，生产部建议在主库上做备份。因为这里的备份考虑到数据的一致性，我们需要先把表都锁起来。禁止写入，但是生产啊，怎么能这样做呢，，只要锁从库-B了。。

1：B库，锁表，禁止写入数据。

记住，一定要停止主从关系后锁表，哈哈，主从都停止了，还有数据写入么。。停止了直接被备份就好了。。。

sql> stop slave;

sql> flush tables with read lock;

sql>flush logs;

sql>create table t7(id int);

sql>create table t8(id int);

sql>flush logs;

sql>create table t9(id int);

sql>create table t10(id int);

3：备份B库。全备？单库备，任你选，但是恢复的方式不一样。因为全备会把GTID信息备份过去，单库备份还原的话不会。

全备:

$ mysqldump -umysql-admin -p –all-databases > all.sqlEnter password: Warning: A partial dump from a server that has GTIDs will by default include the GTIDs of all transactions, even those that changed suppressed parts of the database. If you don’t want to restore GTIDs, pass –set-gtid-purged=OFF. To make a complete dump, pass –all-databases –triggers –routines –events.

发现报错，不过是Warning，说的就是导出GTID，默认情况下导出所有事务，如果你不是用来做slave，就添加–set-gtid-purged=OFF。一个完整的转储， –all-databases –triggers –routines –events。

这样执行就不爆Warning了。

$mysqldump -umysql-admin -p –all-databases –triggers –routines –events –set-gtid-purged=ON > all.sql

4：释放从库B锁，启动slave线程

sql>unlock tables;

sql>start slave;

5：导入数据库C。

$ /usr/local/mysql56/bin/mysql -umysql-admin -p < all.sql

$ /usr/local/mysql56/bin/mysql -umysql-admin -p < all.sql

sql>show databases;

sql>use testuhang;

sql>show tables;

sql>show master status;

sql>change master to master_host=’192.168.112.131′, master_user=’ruser’,master_password=’rpass’,master_auto_position=1;

如果看到以下结果，恭喜你。恢复成功。

sql>show slave status/G