Mysql5.6.21-GTID主从复制
什么是GTID：GTID（global transaction id）是对于一个已提交事务的编号，并且是一个全局唯一编号。 组成部分： UUID+TID 什么是UUID：Mysql实例的唯一标识。 什么是TID：TID代表了该实例上已经提交的事务数量，随着事务提交单调递增。 例子：6dec6fd5-eb1f-
什么是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操作过程。
当A服务器宕机，业务需要切换到B服务器上。需要将C的复制源改成B服务器。
执行以下命令：
CHANGE MASTER TO MASTER_HOST='xxx', MASTER_LOG_FILE='xxx', MASTER_LOG_POS='nnnn'
难点在于，同一个事务在每台机器上的binlog名字和位置都不一样。怎么找到C服务器当前同步停止点，对应服务器B的master_log_file和master_log_pos是什么的时候就称为了难题。这就是MMM，MHA出现的根本原因。
在5.6版本后，Replication的Failover操作过程。
由于同一个事务GTID在所有节点上的值一致。那么根据C服务器当前停止点的GTID就能唯一定位到服务器B的gtid，甚至由于Master_Auto_position功能的出现，我们根本不需要自动GTID的具体值，直接使用
CHANGE MASTER TO MASTER_HOST='xxx', MASTER_AUTO_POSITION命令可以完成故障转移工作。
GTID搭建
实验环境：3台服务器，A，B，C
A：192.168.112.131
B：192.168.112.132
C：192.168.112.129
一：A服务器:192.168.112.131
1：添加复制账号.
sql>GRANT REPLICATION SLAVE ON *.* TO 'ruser'@'192.168.112.%' IDENTIFIED BY 'rpass';
2：配置文件添加以下信息，启用GTID模式。
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.cnf
|
server-id=10 log-slave-updates=true |
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: Yes Slave_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\G
| Retrieved_Gtid_Set: 7edc6fd5-e1bf-11e4-8842-000c29e512d6:1 Executed_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;
2：模拟添加数据，切换binlog日志。
sql>flush logs;
3：查看binlog日志位置，GTID位置。
4：手动清除binlog，模拟binlog过期被清除，这里清除06之前的文件，就是说，t1-t4表的日志会丢失。
sql>purge binary logs to 'mysql-bin.000006';
5：可以通过gitd_purge状态参数看到，GTID被清除的事务序号1-5。
sql>show global variables like '%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.cnf
|
server-id=12 log-slave-updates=true |
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 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\G
|
Slave_IO_Running: Yes 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
呵呵，slave3 建立起来了，虽然数据丢失了，不是我们想要的结果，没办法，日志都没了，怎么复制，不然就违背mysql的复制原理了，但不可否认，是不是符合前面说的，同一个事务所有GTID都是一致的。
六：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;
2：模拟主库现在又有数据写入了。。。。有真实感了没有？
A库：插入几行数据。
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.sql
| Enter 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
报错了，就是说要开启GTID。因为C库是刚初始化的，还没有在my.cnf里面添加GTID参数，添加完后，重起mysql，再次导入。
添加GTID参数后，重启动mysql，再次导入。
$ /usr/local/mysql56/bin/mysql -umysql-admin -p
大功告成。。。。
6：重建立主从关系。
先查看几个表数据的情况。
sql>show databases;
sql>use testuhang;
sql>show tables;
可以看到t1-t6表就对了。锁表前，就是写到t6。
sql>show master status;
看看GTID事务，，数据非常吻合。因为备份的时候，刚好执行了7个事务。
连接主数据库。
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
可以看到retrieved_Gtid_Set的值是8-11，因为1-7的事务是通过恢复出来的，并不是从主库拉取过来的。
下一篇： Oracle之RMAN备份及还原