一、GTID主从复制原理及相关概念:

1、GTID简介:

GTIDGlobal 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节点在执行时也用同样的GTIDbinlog,这样主从同步后,就可通过GTID确定slave节点同步到的位置了。GTID使用master_auto_position=1代替了基于master_log_filemaster_log_pos的主从复制构建方式。

image.png

3、GTID组成:

GTID=server_uuid:transaction_id

(1)server_uuidMySQL实例的唯一标识,每台主机的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、GTIDbinlog之间的对应关系:

假设有4binlogmysql-bin.000001mysql-bin.000002mysql-bin.000003mysql-bin.000004

mysql-bin.000001Previous-GTIDs=emptybinlog_event1-40

mysql-bin.000002Previous-GTIDs=1-40binlog_event41-80

mysql-bin.000003Previous-GTIDs=1-80binlog_event81-120

mysql-bin.000004Previous-GTIDs=1-120binlog_event121-160

假设要寻找GTID=$XMySQL的扫描顺序从最后一个binlog,即mysql-bin.000004开始扫描

如果$X>mysql-bin.000004Previous-GTIDs=1-120,那么GTID肯定在mysql-bin.000004

如果$X<=mysql-bin.000004Previous-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、关闭SELinuxfirewalld

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、warnMySQL 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';

image.png

备注:内容和/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

image.png

image.png

备注:

(1)Slave_IO_RunningSlave_SQL_Running的值,默认为No

(2)自动在/var/lib/mysql数据目录中创建relay-log.000001relay-log.indexrelay-log.info文件

9、slave节点启动复制线程:

mysql> start slave;

备注:

(1)start slave等同于分别执行start slave io_threadstart slave sql_thread

(2)stop slave表示停止主从复制线程

(3)重启slave节点所在的主机,复制线程会自动启动

mysql> show slave status\G

image.png

image.png

image.png

备注:

(1)只有当Slave_IO_RunningSlave_SQL_Running的值都为Yes时,复制线程才算启动成功

(2)Seconds_Behind_Master的值为0,说明slave节点没有落后于master节点

(3)复制时的详细信息记录在slave节点的错误日志/var/log/mysqld.log

(4)slave节点start slave时,会计算show slave statusRetrieved_Gtid_SetExecuted_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;

image.png

mysql> show slave hosts;

image.png

mysql> show global variables like '%gtid%';

image.png

备注:

(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_purgedgtid_executed的子集。只有gtid_executed为空时才能手动设置gtid_purged变量,此时会将gtid_executed更新为和gtid_purged相同的值。

mysql> show variables like '%gtid%';

image.png

备注:gtid_nextsession会话级别的变量,如何产生下一个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;

image.png

11、slave节点查看GTID相关信息:

mysql> show slave status\G

mysql> show global variables like '%gtid%';

image.png

mysql> show variables like '%gtid%';

image.png

mysql> show processlist;

image.png


四、验证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;

image.png

mysql> show master status;

image.png

2、slave节点查看测试数据:

mysql> show databases;

mysql> use db;

mysql> show tables;

mysql> desc tb;

mysql> select * from tb;

image.png

mysql> show slave status\G

mysql> show global variables like '%gtid%';

image.png


五、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、关闭SELinuxfirewalld、配置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;

image.png

mysql> show master status;

image.png

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;

image.png

备注:没有第二次插入的测试数据

mysql> show global variables like '%gtid%';

image.png

备注:此时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;

image.png

mysql> show slave hosts;

image.png

mysql> show processlist;

image.png

18、new slave节点查看GTID相关信息:

mysql> show slave status\G

image.png

image.png

image.png

mysql> show global variables like '%gtid%';

image.png

备注:此时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%';

image.png

mysql> show processlist;

image.png

19、new slave节点查看测试数据:

mysql> use db;

mysql> select * from tb;

image.png


六、主从复制延迟的解决方案及并行复制:

1、主从复制延迟的可能原因:

(1)MySQL主从复制本来就不是实时的,而是异步的,即master节点提交事务之后,slave节点才执行一遍

(2)master节点上对没有索引的大表的列进行deleteupdate操作

(3)slave节点的硬件配置没有master节点好

(4)网络抖动导致slave节点的I/O线程复制延迟

2、主从复制延迟的解决方案:

(1)使用MySQL 5.7版本新增的基于组提交的并行复制功能,即master节点并行执行SQL语句,slave节点也可通过多个workers线程并发执行relay logmaster节点提交的事务

(2)可以采用Percona公司的Percona XtraDB Cluster(简称PXC架构)实现多节点写入,达到实时同步

(3)业务初期规划时就要选择合适的分库、分表策略,避免单表或单库过大,带来额外的复制压力,从而带来主从复制延迟的问题

(4)避免一些无用的I/O消耗,可以增加高转速的硬盘、SSDPCIE-SSD设备

(5)阵列级别要选择RAID 10raid 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%';

image.png


七、主从复制的监控:

1、percona-toolkit工具集中的pt-heartbeat监控原理:

先在master节点指定数据库中创建一张名为heartbeat的表,表中有个时间戳字段tsmaster节点pt-heartbeatupdate线程会在指定时间间隔更新时间戳,而slave节点上的pt-heartbeatmonitor线程会检查复制的心跳记录,这个记录就是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;

image.png

4、所有slave节点执行命令:# pt-heartbeat --master-server-id=1 --monitor -D db -uroot -p123456

image.png

image.png

备注:中括号中的数值分别代表1m5m15m的平均值,上述执行结果表示没有主从复制延迟


八、主从复制的数据校验与修复:

1、主从复制的数据校验、修复过程中需要使用到的工具:

使用percona-toolkit工具集中的pt-table-checksum检查主从节点数据的一致性,使用pt-table-sync修复不一致的数据信息。

2、pt-table-checksum校验比对原理:

pt-table-checksum针对某张表中的所有字段进行hash函数运算,在master节点执行校验查询,把得到的校验值记录为master_crcmaster_cnt,在slave节点也执行校验查询,把得到的校验值记录为this_crcthis_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

image.png

备注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)DIFFS0表示一致,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

image.png

备注:this_crc=master_crcthis_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;

image.png

(2)master节点查看测试数据:

mysql> select * from db.tb;

image.png

(3)new slave节点查看测试数据:

mysql> select * from db.tb;

image.png

9、master节点校验db数据库的tb表信息:

# pt-table-checksum --nocheck-replication-filters --no-check-binlog-format --replicate=db.checksums -d db -t tb -uroot -p123456

image.png

备注:主从节点数据校验和同步的前提条件是主从复制正常运行,此处出现主从表的数据不一致

10、slave节点查看db.checksums表的信息:

mysql> select * from db.checksums\G

image.png

备注:this_crc不等于master_crcthis_cnt不等于master_cnt

11、master节点打印需要执行修复的SQL语句:

# pt-table-sync --replicate=db.checksums h=192.168.1.143,u=root,p=123456 --print

image.png

备注:主要参数说明

(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

image.png

14、slave节点查看db.checksums表的信息:

mysql> select * from db.checksums\G

image.png

备注:this_crc=master_crcthis_cnt=master_cnt

15、slave节点查看测试数据:

mysql> select * from db.tb;

image.png

备注:如果遇到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_RunningSlave_SQL_Running的值均为Yes