一、GTID主从复制原理及相关概念：
1、GTID简介：
GTID：Global Transaction ID，全局事务ID，是一个已提交事务的编号，并且是一个全局唯一的编号。MySQL 5.6版本之后在主从复制类型上新增了GTID复制。通过GTID保证了每个在master节点上提交的事务在集群中有一个唯一的ID，这种方式强化了数据库的主从一致性、故障恢复及容错能力。
2、GTID工作原理：
GTID用于在binlog中唯一标识一个事务。当事务提交时，MySQL在写binlog时，会先写一个特殊的binlog event，类型为GTID_Event，指定下一个事务的GTID，然后再写事务的binlog。主从同步时GTID_Event和事务的binlog都会传递到slave节点，slave节点在执行时也用同样的GTID写binlog，这样主从同步后，就可通过GTID确定slave节点同步到的位置了。GTID使用master_auto_position=1代替了基于master_log_file和master_log_pos的主从复制构建方式。
3、GTID组成：
GTID=server_uuid:transaction_id
（1）server_uuid：MySQL实例的唯一标识，每台主机的server_uuid都不同（128位），保存在数据目录下的auto.cnf文件中。MySQL第一次启动时创建auto.cnf文件，并生成server_uuid，之后MySQL再次启动时不会重复生成server_uuid，而是使用auto.cnf中的server_uuid。
（2）transaction_id：事务提交时由系统顺序分配的一个不会重复的序列号，代表了该实例上已经提交的事务数量，一般来说随着事务提交递增。
备注：使用server_uuid:transaction_id共同组成一个GTID的好处是，由于server_uuid唯一，即使一个集群内多个节点同时写入，也不会造成GTID冲突。
4、GTID使用限制：
（1）不支持create table ... select语句
（2）不支持针对临时表的操作，即create | drop temporary table
（3）不支持非事务存储引擎（如：MyISAM）
（4）不支持sql_slave_skip_counter
5、GTID和binlog之间的对应关系：
假设有4个binlog：mysql-bin.000001、mysql-bin.000002、mysql-bin.000003、mysql-bin.000004
mysql-bin.000001：Previous-GTIDs=empty，binlog_event有1-40
mysql-bin.000002：Previous-GTIDs=1-40，binlog_event有41-80
mysql-bin.000003：Previous-GTIDs=1-80，binlog_event有81-120
mysql-bin.000004：Previous-GTIDs=1-120，binlog_event有121-160
假设要寻找GTID=$X，MySQL的扫描顺序从最后一个binlog，即mysql-bin.000004开始扫描
如果$X>mysql-bin.000004的Previous-GTIDs=1-120，那么GTID肯定在mysql-bin.000004中
如果$X<=mysql-bin.000004的Previous-GTIDs=1-120，那么继续比对mysql-bin.000003，然后再循环，直到找到为止
二、准备工作（两个节点都需要执行如下操作）：
1、演示环境：
IP |
操作系统 |
主机名 |
角色 |
数据库版本 |
安装方式 |
192.168.1.143 |
CentOS 7.6 x86_64 |
node1 |
master |
5.7.26-29-log Percona Server |
yum |
192.168.1.144 |
CentOS 7.6 x86_64 |
node2 |
slave |
5.7.26-29-log Percona Server |
yum |
2、关闭SELinux和firewalld
3、配置epel源
4、配置percona源：
# yum -y install https://repo.percona.com/yum/percona-release-latest.noarch.rpm
# yum repolist
# yum list | grep -i percona
5、配置服务器时间同步
6、配置主机名
7、配置/etc/hosts文件：
# vim /etc/hosts
192.168.1.143 node1
192.168.1.144 node2
三、安装Percona Server，并配置GTID主从复制（如未特殊说明，两个节点都需要执行如下操作）：
1、安装Percona Server：# yum -y install Percona-Server-server-57
2、修改MySQL配置文件：
# mv /etc/my.cnf /etc/my.cnf.bak
# update-alternatives --install /etc/my.cnf my.cnf "/etc/percona-server.cnf" 200
# vim /etc/percona-server.conf.d/mysqld.cnf
master节点：
[mysqld]
port=3306
socket=/var/lib/mysql/mysql.sock
datadir=/var/lib/mysql
pid-file=/var/run/mysqld/mysqld.pid
log-error=/var/log/mysqld.log
lower_case_table_names=1
character_set_server=utf8mb4
collation_server=utf8mb4_general_ci
innodb_file_per_table=1
skip_name_resolve=1
slow_query_log=1
slow_query_log_file=mysql-slow.log
symbolic-links=0
explicit_defaults_for_timestamp=1
log_bin=mysql-bin
log_bin_index=mysql-bin.index
binlog_format=row
server_id=1
sync_binlog=1
innodb_flush_log_at_trx_commit=1
gtid_mode=on
enforce_gtid_consistency=on
备注：
（1）从MySQL 5.7版本开始，gtid_mode支持动态修改，gtid_mode的可取值为：
a、off：不支持GTID事务，生成的是匿名事务，slave节点也只能应用匿名事务
b、off_permissive：生成的是匿名事务，slave节点可以应用匿名事务和GTID事务
c、on_permissive：生成的是GTID事务，slave节点可以应用匿名事务和GTID事务（此步骤操作完成后，master节点的二进制日志就会变成GTID模式）
d、on：支持GTID事务，生成的是GTID事务，slave节点也只能应用GTID事务
注意：在生产环境中，可能有把传统复制改为GTID复制模式的需求，gtid_mode虽然支持动态修改，但不支持跳跃式修改，比如从on_permissive修改为off是不可以的
（2）enforce_gtid_consistency主要用于不让违反GTID的操作执行，可取值为：
a、off：允许所有操作
b、on：不允许有违反GTID的操作，且报错
c、warn：MySQL 5.7版本新增，允许所有操作，但是违反GTID的操作会提示警告
slave节点：
[mysqld]
port=3306
socket=/var/lib/mysql/mysql.sock
datadir=/var/lib/mysql
pid-file=/var/run/mysqld/mysqld.pid
log-error=/var/log/mysqld.log
lower_case_table_names=1
character_set_server=utf8mb4
collation_server=utf8mb4_general_ci
innodb_file_per_table=1
skip_name_resolve=1
slow_query_log=1
slow_query_log_file=mysql-slow.log
symbolic-links=0
explicit_defaults_for_timestamp=1
relay_log=relay-log
relay_log_index=relay-log.index
server_id=2
read_only=1
gtid_mode=on
enforce_gtid_consistency=on
备注：
（1）slave节点只能读不能写
（2）中继日志默认不存在
（3）MySQL 5.6版本中使用GTID复制模式，必须要开启参数log_slave_updates=1，但在MySQL 5.7版本中使用gtid_executed系统表记录已经执行的GTID集合信息，所以就不用开启参数log_slave_updates=1，开启的意义是把relay log中的日志内容再次记录到slave节点的本地binlog中
3、初始化MySQL数据：# mysqld --initialize --user=mysql
备注：确保初始化前/var/lib/mysql目录为空，初始化完成后会在此目录中生成各类文件
4、启动MySQL服务：
# systemctl start mysqld.service
# ss -tunlp | grep mysqld
# systemctl enable mysqld.service
# systemctl status mysqld.service
5、查看root@localhost用户的初始密码：# grep password /var/log/mysqld.log
6、配置MySQL安全向导：# mysql_secure_installation
7、master节点创建具有复制权限的用户repluser：
# mysql -uroot -p
mysql> create user 'repluser'@'192.168.1.%' identified by '123456';
mysql> grant replication slave on *.* to 'repluser'@'192.168.1.%';
mysql> flush privileges;
mysql> show global variables like 'server_uuid';
备注：内容和/var/lib/mysql/auto.cnf文件中的内容一致
8、slave节点使用具有复制权限的用户repluser连接至master节点：
# mysql -uroot -p
mysql> change master to master_host='192.168.1.143',master_user='repluser',master_password='123456',master_port=3306,master_auto_position=1;
mysql> show slave status\G
备注：
（1）Slave_IO_Running和Slave_SQL_Running的值，默认为No
（2）自动在/var/lib/mysql数据目录中创建relay-log.000001、relay-log.index和relay-log.info文件
9、slave节点启动复制线程：
mysql> start slave;
备注：
（1）start slave等同于分别执行start slave io_thread和start slave sql_thread
（2）stop slave表示停止主从复制线程
（3）重启slave节点所在的主机，复制线程会自动启动
mysql> show slave status\G
备注：
（1）只有当Slave_IO_Running和Slave_SQL_Running的值都为Yes时，复制线程才算启动成功
（2）Seconds_Behind_Master的值为0，说明slave节点没有落后于master节点
（3）复制时的详细信息记录在slave节点的错误日志/var/log/mysqld.log中
（4）slave节点start slave时，会计算show slave status中Retrieved_Gtid_Set和Executed_Gtid_Set的并集，然后将此GTID并集发送给master节点。master节点会使用slave节点请求的GTID集合和master节点自身的gtid_executed比较，把slave节点GTID集合里缺失的事务全部发送给slave节点。如果slave节点缺失的GTID已经被master节点清除，则slave节点会提示1236错误，I/O线程中断。
10、master节点查看GTID相关信息：
mysql> show master status;
mysql> show slave hosts;
mysql> show global variables like '%gtid%';
备注：
（1）gtid_executed：当前实例上已经执行过的GTID集合，实际上包含了所有记录到binlog中的事务。如果set sql_log_bin=0，执行的事务不会生成binlog事件，也不会记录到gtid_executed中。执行reset master可以将变量@@global.gtid_executed清空。
（2）gtid_owned：当前实例正在执行中的GTID，以及对应的线程ID
（3）gtid_purged：记录当前实例执行过，但已被清除的GTID集合。gtid_purged是gtid_executed的子集。只有gtid_executed为空时才能手动设置gtid_purged变量，此时会将gtid_executed更新为和gtid_purged相同的值。
mysql> show variables like '%gtid%';
备注：gtid_next，session会话级别的变量，如何产生下一个GTID，可取值为
（1）automatic：默认取值，在每次事务提交时自动生成新的GTID，它从当前已执行的GTID集合（即gtid_executed）中，找一个大于0的、未使用的transaction_id最小值作为下个事务的GTID，同时在binlog的实际更新事务事件前插入一条set gtid_next事件，所以即使是同一个server_uuid，也不能通过transaction_id的大小来判断事务的顺序。
（2）anonymous：执行事务不会产生GTID
（3）显示指定GTID：可以指定任意合法的GTID，但不能是当前gtid_executed中已经包含的GTID
mysql> show processlist;
11、slave节点查看GTID相关信息：
mysql> show slave status\G
mysql> show global variables like '%gtid%';
mysql> show variables like '%gtid%';
mysql> show processlist;
四、验证GTID主从复制：
1、master节点创建测试数据：
mysql> create database db;
mysql> use db;
mysql> create table tb(id int unsigned auto_increment primary key not null,age int not null);
mysql> desc tb;
mysql> insert into tb(age) values(35),(40);
mysql> select * from tb;
mysql> show master status;
2、slave节点查看测试数据：
mysql> show databases;
mysql> use db;
mysql> show tables;
mysql> desc tb;
mysql> select * from tb;
mysql> show slave status\G
mysql> show global variables like '%gtid%';
五、新slave节点加入GTID主从复制（如未特殊说明，在new slave节点执行如下操作）：
1、演示环境：
IP |
操作系统 |
主机名 |
角色 |
数据库版本 |
安装方式 |
192.168.1.143 |
CentOS 7.6 x86_64 |
node1 |
master |
5.7.26-29-log Percona Server |
yum |
192.168.1.144 |
CentOS 7.6 x86_64 |
node2 |
slave |
5.7.26-29-log Percona Server |
yum |
192.168.1.145 |
CentOS 7.6 x86_64 |
node3 |
new slave |
5.7.26-29-log Percona Server |
yum |
2、关闭SELinux和firewalld、配置epel源、配置服务器时间同步、配置主机名
3、配置percona源：
# yum -y install https://repo.percona.com/yum/percona-release-latest.noarch.rpm
# yum repolist
# yum list | grep -i percona
4、三个节点配置/etc/hosts文件：
# vim /etc/hosts
192.168.1.143 node1
192.168.1.144 node2
192.168.1.145 node3
5、安装Percona Server：# yum -y install Percona-Server-server-57
6、修改MySQL配置文件：
# mv /etc/my.cnf /etc/my.cnf.bak
# update-alternatives --install /etc/my.cnf my.cnf "/etc/percona-server.cnf" 200
# vim /etc/percona-server.conf.d/mysqld.cnf
[mysqld]
port=3306
socket=/var/lib/mysql/mysql.sock
datadir=/var/lib/mysql
pid-file=/var/run/mysqld/mysqld.pid
log-error=/var/log/mysqld.log
lower_case_table_names=1
character_set_server=utf8mb4
collation_server=utf8mb4_general_ci
innodb_file_per_table=1
skip_name_resolve=1
slow_query_log=1
slow_query_log_file=mysql-slow.log
symbolic-links=0
explicit_defaults_for_timestamp=1
relay_log=relay-log
relay_log_index=relay-log.index
server_id=3
read_only=1
gtid_mode=on
enforce_gtid_consistency=on
7、初始化MySQL数据：# mysqld --initialize --user=mysql
8、启动MySQL服务：
# systemctl start mysqld.service
# ss -tunlp | grep mysqld
# systemctl enable mysqld.service
# systemctl status mysqld.service
9、查看root@localhost用户的初始密码：# grep password /var/log/mysqld.log
10、配置MySQL安全向导：# mysql_secure_installation
11、master节点使用mysqldump命令为其所有库的所有表做一个全量热备：
# mkdir -pv /backup
# mysqldump -E -R -q --single-transaction -A -uroot -p > /backup/all_`date +%F`.sql
备注：生成的all_2019-06-12.sql备份文件中有类似如下语句
SET @@GLOBAL.GTID_PURGED='492a33c3-8d01-11e9-9e17-005056bf3e78:1-9';
12、master节点将all_2019-06-12.sql备份文件发送至new slave节点：
# scp -p /backup/all_2019-06-12.sql node3:/backup
13、master节点在db数据库的tb表中插入测试数据，模拟备份后的数据变动：
mysql> use db;
mysql> insert into tb(age) values(0),(100);
mysql> select * from tb;
mysql> show master status;
14、new slave节点清空gtid_executed变量的值，并恢复数据：
# mysql -uroot -p -e 'reset master;'
# mysql -uroot -p < /backup/all_2019-06-12.sql
15、new slave节点查看测试数据：
# mysql -uroot -p
mysql> show databases;
mysql> use db;
mysql> show tables;
mysql> desc tb;
mysql> select * from tb;
备注：没有第二次插入的测试数据
mysql> show global variables like '%gtid%';
备注：此时master节点的gtid_executed值为492a33c3-8d01-11e9-9e17-005056bf3e78:1-10
16、new slave节点使用具有复制权限的用户repluser连接至master节点，并启动复制线程：
mysql> change master to master_host='192.168.1.143',master_user='repluser',master_password='123456',master_port=3306,master_auto_position=1;
mysql> start slave;
17、master节点查看GTID相关信息：
mysql> show master status;
mysql> show slave hosts;
mysql> show processlist;
18、new slave节点查看GTID相关信息：
mysql> show slave status\G
mysql> show global variables like '%gtid%';
备注：此时new slave节点show slave status命令执行结果中的Executed_Gtid_Set值和master节点show master status命令执行结果中的Executed_Gtid_Set值相同，均为492a33c3-8d01-11e9-9e17-005056bf3e78:1-10
mysql> show variables like '%gtid%';
mysql> show processlist;
19、new slave节点查看测试数据：
mysql> use db;
mysql> select * from tb;
六、主从复制延迟的解决方案及并行复制：
1、主从复制延迟的可能原因：
（1）MySQL主从复制本来就不是实时的，而是异步的，即master节点提交事务之后，slave节点才执行一遍
（2）在master节点上对没有索引的大表的列进行delete或update操作
（3）slave节点的硬件配置没有master节点好
（4）网络抖动导致slave节点的I/O线程复制延迟
2、主从复制延迟的解决方案：
（1）使用MySQL 5.7版本新增的基于组提交的并行复制功能，即master节点并行执行SQL语句，slave节点也可通过多个workers线程并发执行relay log中master节点提交的事务
（2）可以采用Percona公司的Percona XtraDB Cluster（简称PXC架构）实现多节点写入，达到实时同步
（3）业务初期规划时就要选择合适的分库、分表策略，避免单表或单库过大，带来额外的复制压力，从而带来主从复制延迟的问题
（4）避免一些无用的I/O消耗，可以增加高转速的硬盘、SSD或PCIE-SSD设备
（5）阵列级别要选择RAID 10，raid cache策略要使用WB，坚决不使用WT
（6）I/O调度要选择deadline模式
（7）适当调整buffer pool的大小
（8）避免让数据库进行各种大量运算，数据库是用来存储数据的，让应用端多分担些压力，或通过缓存来完成
3、配置并行复制：
（1）所有slave节点修改MySQL配置文件，在[mysqld]配置段中新增如下2个参数：
# vim /etc/percona-server.conf.d/mysqld.cnf
[mysqld]
slave_parallel_workers=16
slave_parallel_type=logical_clock
# systemctl restart mysqld.service
# ss -tunlp | grep mysqld
# systemctl status mysqld.service
# tail -100 /var/log/mysqld.log
（2）所有slave节点查看相关变量：
mysql> show global variables like '%slave_parallel%';
七、主从复制的监控：
1、percona-toolkit工具集中的pt-heartbeat监控原理：
先在master节点指定数据库中创建一张名为heartbeat的表，表中有个时间戳字段ts，master节点pt-heartbeat的update线程会在指定时间间隔更新时间戳，而slave节点上的pt-heartbeat的monitor线程会检查复制的心跳记录，这个记录就是master节点修改的时间戳，然后和当前系统时间进行比对，得出时间上的差异，差异值就是延迟的时间大小，由于heartbeat表中有server_id字段，在监控某个slave节点的延迟时指定参考master节点的server_id即可。
2、所有节点安装percona-toolkit：
# yum -y install https://repo.percona.com/yum/percona-release-latest.noarch.rpm
# yum repolist
# yum list | grep -i percona
# yum -y install percona-toolkit
3、master节点创建heartbeat心跳表，并通过update更新时间戳，心跳表建立在db数据库下：
# pt-heartbeat -uroot -p123456 -D db --update --create-table --daemonize
备注：主要参数说明
（1）-u：连接数据库的用户
（2）-p：连接数据库的密码，此处要明文指定
（3）-D：连接的数据库名称
（4）--update：更新master节点的心跳表
（5）--create-table：在master节点创建心跳监控表
（6）--daemonize：以守护进程方式运行
（7）-h：连接数据库的地址
（8）-P：连接数据库的端口
（9）--monitor：持续监控slave节点的延迟情况
（10）--master-server-id：指定master节点的server_id，若没有指定，则该工具会连到master节点查找其server_id
# mysql -uroot -p
mysql> use db;
mysql> show tables;
mysql> select * from heartbeat;
4、所有slave节点执行命令：# pt-heartbeat --master-server-id=1 --monitor -D db -uroot -p123456
备注：中括号中的数值分别代表1m、5m和15m的平均值，上述执行结果表示没有主从复制延迟
八、主从复制的数据校验与修复：
1、主从复制的数据校验、修复过程中需要使用到的工具：
使用percona-toolkit工具集中的pt-table-checksum检查主从节点数据的一致性，使用pt-table-sync修复不一致的数据信息。
2、pt-table-checksum校验比对原理：
pt-table-checksum针对某张表中的所有字段进行hash函数运算，在master节点执行校验查询，把得到的校验值记录为master_crc、master_cnt，在slave节点也执行校验查询，把得到的校验值记录为this_crc、this_cnt，最后通过比对slave节点的this值和master节点master值来判断主从之间的数据一致性，并输出比对结果。
3、pt-table-sync同步数据原理：
pt-table-sync高效同步MySQL表之间的数据，可以单向或双向同步表数据，也可以同步单个表，或同步整个数据库，但不同步表结构、索引、或任何其它模式对象，所以在修复之前确保表存在。
4、master节点授权一个能登录所有节点的用户，该用户的授权操作会同步至所有slave节点：
# mysql -uroot -p
mysql> create user 'root'@'192.168.1.143' identified by '123456';
mysql> grant all on *.* to 'root'@'192.168.1.143';
mysql> flush privileges;
5、所有slave节点修改MySQL配置文件，在[mysqld]配置段中新增如下2个参数：
# vim /etc/percona-server.conf.d/mysqld.cnf
slave节点：
[mysqld]
report_host=192.168.1.144
report_port=3306
new slave节点：
[mysqld]
report_host=192.168.1.145
report_port=3306
# systemctl restart mysqld.service
# ss -tunlp | grep mysqld
# systemctl status mysqld.service
# tail -100 /var/log/mysqld.log
6、master节点校验db数据库的tb表信息：
# pt-table-checksum --nocheck-replication-filters --no-check-binlog-format --replicate=db.checksums -d db -t tb -uroot -p123456
备注1：主要参数说明
（1）--nocheck-replication-filters：不检查复制过滤器，建议启用
（2）--nocheck-binlog-format：不检查binlog模式，建议启用，因为在row模式下会报错
（3）--replicate-check-only：只显示不同步的信息
（4）--replicate：把checksum的信息写入到指定表中，建议直接写入被检查的数据库中，也可以指定不存在的数据库，校验时会自动创建该数据库，在该数据库下生成检查表
（5）-d：指定需要被检查的数据库，多个库之间可以用逗号分隔
（6）-t：指定需要被检查的表，多个表之间用逗号分隔
（7）--where：大表校验的过程，可以使用where来过滤条件
备注2：输出结果说明
（1）TS：完成检查的时间
（2）ERRORS：检查时发生错误和警告的数量
（3）DIFFS：0表示一致，1表示不一致，当指定--no-replicate-check时会一直为0，当指定--replicate-check-only时会显示不同的信息，此次演示中主从表的数据一致
（4）ROWS：表的行数，此次演示中db数据库的tb表中有4条记录
（5）CHUNKS：被划分到表中的块的数目
（6）SKIPPED：由于错误或警告或过大，跳过块的数目
（7）TIME：执行校验的时间
（8）TABLE：被检查的表名，此次演示中为db数据库的tb表
（9）上述命令执行成功后，会在所有节点的db数据库中生成一张名为checksums的表
7、所有节点查看db.checksums表的信息：
mysql> select * from db.checksums\G
备注：this_crc=master_crc、this_cnt=master_cnt
8、模拟主从表的数据不一致：
（1）slave节点在db数据库的tb表中删除2条测试数据：
mysql> use db;
mysql> delete from tb where age in (0,100);
mysql> select * from tb;
（2）master节点查看测试数据：
mysql> select * from db.tb;
（3）new slave节点查看测试数据：
mysql> select * from db.tb;
9、master节点校验db数据库的tb表信息：
# pt-table-checksum --nocheck-replication-filters --no-check-binlog-format --replicate=db.checksums -d db -t tb -uroot -p123456
备注：主从节点数据校验和同步的前提条件是主从复制正常运行，此处出现主从表的数据不一致
10、slave节点查看db.checksums表的信息：
mysql> select * from db.checksums\G
备注：this_crc不等于master_crc、this_cnt不等于master_cnt
11、master节点打印需要执行修复的SQL语句：
# pt-table-sync --replicate=db.checksums h=192.168.1.143,u=root,p=123456 --print
备注：主要参数说明
（1）--replicate：指定通过pt-table-checksum得到的表
（2）--print：打印但不执行命令
（3）--execute：执行命令
（4）-d：指定需要执行同步的数据库，多个库之间可以用逗号分隔
（5）-t：指定需要执行同步的表，多个表之间用逗号分隔
12、master节点修复主从表的不一致数据：
# pt-table-sync --replicate=db.checksums h=192.168.1.143,u=root,p=123456 --execute
13、master节点校验db数据库的tb表信息：
# pt-table-checksum --nocheck-replication-filters --no-check-binlog-format --replicate=db.checksums -d db -t tb -uroot -p123456
14、slave节点查看db.checksums表的信息：
mysql> select * from db.checksums\G
备注：this_crc=master_crc、this_cnt=master_cnt
15、slave节点查看测试数据：
mysql> select * from db.tb;
备注：如果遇到slave节点启动复制线程后，Slave_IO_Running的值为Yes，而Slave_SQL_Running的值为No，且Last_Error: Coordinator stopped because there were error(s) in the worker(s). The most recent failure being: Worker 1 failed executing transaction '492a33c3-8d01-11e9-9e17-005056bf3e78:42227' at master log mysql-bin.000002, end_log_pos 16004080. See error log and/or performance_schema.replication_applier_status_by_worker table for more details about this failure or others, if any. 可执行如下命令：
mysql> stop slave;
mysql> set gtid_next='492a33c3-8d01-11e9-9e17-005056bf3e78:42227';
mysql> begin;
mysql> commit;
mysql> set gtid_next='automatic';
mysql> start slave;
此时slave节点成功启动复制线程，且Slave_IO_Running和Slave_SQL_Running的值均为Yes