杰霸霸博客

主题

mysql主从(GTID) ​

使用KeepAlived实现读写分离和自动转换和读写使用VIP。

1. 原理 ​

GTID是一个基于原始mysql服务器生成的一个已经被成功执行的全局事务ID，它由服务器ID以及事务ID组合而成。

2. GTID优势 ​

更简单的实现failover，不用以前那样在需要找位点（log_file 和 log_pos）。
更简单的搭建主从复制。
比传统的复制更加安全。
GTID是连续的没有空洞的，保证数据的一致性，零丢失。

3. GTID工作原理 ​

主库计算主库GTID集合和从库GTID的集合的差集，主库推送差集binlog给从库。 当从库设置完同步参数后，主库A的GTID集合记为集合x，从库B的GTID集合记为y
Alt text

  1. 从库B指定主库A，基于主备协议建立连接。
  2. 从库B把集合y发给主库A。
  3. 主库A计算出集合x和集合y的差集，也就是集合x中存在，集合y中不存在的GTID集合。比如集合x是1~100，集合y是1~90，那么这个差集就是91~100。这里会判断集合x是不是包含有集合y的所有GTID，如果不是则说明主库A删除了从4库B需要的binlog，主库A直接返回错误。
  4. 主库A从自己的binlog文件里面，找到第一个不在集合y中的事务GTID，也就是找到了91。
  5. 主库A从GTID=91的事务开始，往后读binlog文件，按顺序取 binlog，然后发给B。
  6. 从库B的I/O线程读取binlog文件生成relay log，SQL线程解析relay log，然后执行SQL语句。

4. GTID主从复制实践 ​

数据库的安装请参考MySQL安装(Ubuntu版)

4.1 配置Master数据库 ​

配置master的my.cnf文件

sh
jack@mysql01:~$ vim /etc/mysql/mysql.conf.d/mysqld.cnf
## 以下为配置的内容
pid-file        = /var/run/mysqld/mysqld.pid
socket          = /var/run/mysqld/mysqld.sock
datadir         = /var/lib/mysql
log-error       = /var/log/mysql/error.log
## 以下为配置的内容
#Mysql服务的唯一编号 每个mysql服务Id需唯一
server-id=1
#服务端口号 默认3306
port=3306
#user=mysql
#开启慢查询日志
slow_query_log=1
#慢查询时间 超过3秒则为慢查询
long_query_time=3
#慢查询日志目录
slow_query_log_file=/var/log/mysql/mysql-slow.log
#数据库默认字符集,主流字符集支持一些特殊表情符号(特殊表情符占用4个字节)
character-set-server=utf8mb4
#数据库字符集对应一些排序等规则，注意要和character-set-server对应
collation-server=utf8mb4_general_ci
#最大连接数
max_connections=400

log-bin=mysql-bin
binlog-ignore-db=mysql
binlog-ignore-db=performance_schema
binlog-ignore-db=sys
binlog-ignore-db=information_schema
#GTID 复制时，binlog 使用 ROW 模式
binlog_format=row

#gtid 参数
gtid_mode=ON
enforce-gtid-consistency=ON
slave-parallel-workers=4

创建同步数据的用户：

sh
mysql> CREATE USER 'slave'@'%' IDENTIFIED BY '123456';
mysql> GRANT REPLICATION SLAVE,USAGE, REPLICATION CLIENT ON *.* TO 'slave'@'%';
mysql> ALTER USER 'slave'@'%' IDENTIFIED WITH mysql_native_password BY '123456';
mysql> FLUSH PRIVILEGES;

4.2 配置slave数据库 ​

配置slave的my.cnf文件

sh
jack@mysql01:~$ vim /etc/mysql/mysql.conf.d/mysqld.cnf
## 以下为配置的内容
pid-file        = /var/run/mysqld/mysqld.pid
socket          = /var/run/mysqld/mysqld.sock
datadir         = /var/lib/mysql
log-error       = /var/log/mysql/error.log
#Mysql服务的唯一编号 每个mysql服务Id需唯一
server-id=2
#服务端口号 默认3306
port=3306
#开启慢查询日志
slow_query_log=1
#慢查询时间 超过3秒则为慢查询
long_query_time=3
#慢查询日志目录
slow_query_log_file=/var/log/mysql/mysql-slow.log
#数据库默认字符集,主流字符集支持一些特殊表情符号(特殊表情符占用4个字节)
character-set-server=utf8mb4
#数据库字符集对应一些排序等规则，注意要和character-set-server对应
collation-server=utf8mb4_general_ci
#最大连接数
max_connections=400

log-bin=mysql-bin
binlog-ignore-db=mysql
binlog-ignore-db=performance_schema
binlog-ignore-db=sys
binlog-ignore-db=information_schema
#GTID 复制时，binlog 使用 ROW 模式
binlog_format=row

#gtid 参数
gtid_mode=ON
enforce-gtid-consistency=ON
## slave设置为只读（具有super权限的用户除外）
read-only=1
super_read_only=1
slave-parallel-workers=4

创建同步数据的用户：

sh
mysql> CREATE USER 'slave'@'%' IDENTIFIED BY '123456';
mysql> GRANT REPLICATION SLAVE,USAGE, REPLICATION CLIENT ON *.* TO 'slave'@'%';
mysql> ALTER USER 'slave'@'%' IDENTIFIED WITH mysql_native_password BY '123456';
mysql> FLUSH PRIVILEGES;

5. Slave连接到Master ​

在Slave机器上执行：

sh
mysql> CHANGE MASTER TO MASTER_HOST='192.168.154.221',MASTER_PORT=3306,MASTER_USER='slave', MASTER_PASSWORD='123456',MASTER_AUTO_POSITION=1;
mysql> start slave;

6. Master连接到Slave ​

在Master机器上执行：

sh
mysql> CHANGE MASTER TO MASTER_HOST='192.168.154.222',MASTER_PORT=3306,MASTER_USER='slave', MASTER_PASSWORD='123456',MASTER_AUTO_POSITION=1;
mysql> start slave;

Master和Slave节点互相同步不会发生死循环，因为底层基于事务Id进行的同步，当已经同步的数据包含了该事务Id，就会不再同步。

7. 安装配置KeepAlived ​

Keepalived是一款用于实现高可用性和负载均衡的开源软件，它运行在Linux系统上，可以将多个服务器节点组合成一个虚拟服务器，通过IP地址漂移技术实现故障转移和负载均衡。
Keepalived支持VRRP（虚拟路由冗余协议）和LVS（Linux虚拟服务器）两种模式，可以根据实际需求选择使用。VRRP模式可以实现在多个节点之间自动切换VIP（虚拟 IP）地址，确保在某个节点故障时，其他节点可以接管服务并保证服务的连续性。而LVS模式则可以在多个节点之间分配流量，实现负载均衡。

7.1 安装keepalived ​

在master和slave上面都执行安装keepalived：

sh
jack@mysql01: sudo apt install keepalived -y
jack@mysql02: sudo apt install keepalived -y

7.2 编写检测脚本 ​

在/usr/local/scripts/目录下创建chk_mysql_alived.sh

sh
#!bin/bash

ss -tnl|grep 3306 >/dev/null 2>&1

if [ $? -eq 0 ]
then
    echo " mysql is alived "  
    exit 0
else
    echo " mysql is dead "
    exit 2
fi

其中0表示正常，非0值表示不正常(官方设定的)。

7.3 编写节点变成master后处理脚本 ​

由于我们的主从数据库是读写分离的，从数据库只能读数据(两个都写数据容易发生数据不一致的问题)。

  1. 在Master节点上的编写/usr/local/scripts/change_mysql_status.sh脚本
sh
#!/bin/bash

## 记录变更的时间
echo "change it: $(date '+%Y-%m-%d %H:%M:%S')" >> /tmp/msg.log
## 从节点继续同步数据，并设置只读
mysql -h192.168.154.222 -uroot -proot -e "start slave; set global read_only=1; set global super_read_only=1;"
## 记录结束
echo "设置192.168.154.222只读成功" >> /tmp/msg.log
  1. 在Slave节点上的编写/usr/local/scripts/change_mysql_status.sh脚本
sh
#!/bin/bash
## 记录变更的时间
echo "change it: $(date '+%Y-%m-%d %H:%M:%S')" >> /tmp/msg.log
## 从节点此时是Master, 关闭同步数据，并设置可写可读
mysql -uroot -proot -e "stop slave; set global read_only=0; set global super_read_only=0;"
## 记录结束
echo "设置192.168.154.222可读可写成功" >> /tmp/msg.log

7.4 配置keepalived ​

  1. 在master创建keepalived.conf文件：
sh
sudo vim /etc/keepalived/keepalived.conf
global_defs  {
        router_id LVS_DEVEL_1  ## 全局的id, 可以任意
}
vrrp_script chk_mysql {
    script "/usr/local/scripts/chk_mysql_alived.sh"   # 检测脚本
    interval 1      # 检测频率为每隔1s
    fall 1           # 连续失败次数  
    rise 1           # 连续成功次数
    weight -50     # 权重，分大于0和小于0两种计算逻辑
}

vrrp_instance VI_1 {
    interface wlo1                 # 你的网卡名字，可以使用ip addr命令查看
    state BACKUP                     #设置角色，这里为主设备
    virtual_router_id 51             #设置虚拟路由器ID组，主备一致
    priority 120                    #初始权重，数值越大，优先级越高
    #nopreempt     ## 网上有误导，加上就不会生效自动master/slave切换，需要注释掉
    advert_int 0.5                     #vrrp组之间的心跳包频率，1s 
    preempt_delay 0                  # 0 表示立即抢占（默认）  
    authentication {                 #组认证信息
        auth_type PASS               #认证方式，密码
        auth_pass 12345              #认证密码
    }
    virtual_ipaddress {
       192.168.154.220                #虚拟IP地址
    }
    track_script {                   #使用健康检查脚本
        chk_mysql
    }
    ## 节点变成master 执行的操作
    notify_master "/usr/local/scripts/change_mysql_status.sh"
}

keepalived的主备切换逻辑

主要是看weight配置的值是正数还是负数：

  1. 如果weight配置的值大于0，检测脚本执行结果为0，并检测结果次数达到配置的rise则该节点优先级priority相应的增加。
  2. 如果weight配置的值小于0，检测脚本执行结果非0，并检测结果次数达到配置的fall则该节点优先级priority相应的减少。
  3. 其他情况，维持原本配置的优先级，即配置文件中priority对应的值。
    当计算结果主priority < 从priority，就会发生发生主从切换
  1. 在slave创建keepalived.conf文件：
sh
sudo vim /etc/keepalived/keepalived.conf
global_defs  {
        router_id LVS_DEVEL_1
}
vrrp_script chk_mysql {
    script "/usr/local/scripts/chk_mysql_alived.sh"
    interval 1      # 检测频率为每隔1s
    fall 1           # 连续失败次数  
    rise 1           # 连续成功次数
    weight -50
}

vrrp_instance VI_1 {
    interface wlo1                 # 根据你的网络接口名称调整
    state BACKUP                     #设置角色，这里为主设备
    virtual_router_id 51             #设置虚拟路由器ID组，主备一致
    priority 100                    #优先级，数值越大，优先级越高
    #nopreempt
    advert_int 0.5                     #vrrp组之间的心跳包频率，1s 
    preempt_delay 0  # 0 表示立即抢占（默认）  
    authentication {                 #组认证信息
        auth_type PASS               #认证方式，密码
        auth_pass 12345              #认证密码
    }
    virtual_ipaddress {
       192.168.154.220                #虚拟IP地址
    }
    track_script {                   #健康检查脚本
        chk_mysql
    }
    notify_master "/usr/local/scripts/change_mysql_status.sh"
}

提示

  1. weight值设置的讲究 weight值设置为：weight > |主priority-从priority|
  2. keepalived支持3种事件通知：
    notify_master "/etc/keepalived/notify1.sh" 当前节点成为主节点时触发的脚本
    notify_backup "/etc/keepalived/notify2.sh" 当前节点转为备节点时触发的脚本
    notify_fault "/etc/keepalived/notify3.sh " 当前节点转为“失败”状态时触发的脚本

7.5 查看KeepAlived日志 ​

通过日志可以知道当前节点的priority值，以及主备切换过程：

sh
jack@mysql01:~$ journalctl -u keepalived -f 
4月 09 13:41:36 mysql01 Keepalived[7282]: Starting VRRP child process, pid=7283
4月 09 13:41:36 mysql01 Keepalived_vrrp[7283]: Unable to resolve script username 'keepalived_script' - ignoring
4月 09 13:41:36 mysql01 Keepalived_vrrp[7283]: SECURITY VIOLATION - scripts are being executed but script_security not enabled.
4月 09 13:41:36 mysql01 Keepalived_vrrp[7283]: (VI_1) Warning - nopreempt will not work with initial state MASTER - clearing
4月 09 13:41:36 mysql01 Keepalived_vrrp[7283]: (VI_1) Entering BACKUP STATE (init)
4月 09 13:41:36 mysql01 Keepalived[7282]: Startup complete
4月 09 13:41:36 mysql01 systemd[1]: Started keepalived.service - Keepalive Daemon (LVS and VRRP).
4月 09 13:41:36 mysql01 Keepalived_vrrp[7283]: Script `chk_mysql` now returning 2
4月 09 13:41:36 mysql01 Keepalived_vrrp[7283]: VRRP_Script(chk_mysql) failed (exited with status 2)
4月 09 13:41:36 mysql01 Keepalived_vrrp[7283]: (VI_1) Changing effective priority from 120 to 70
4月 09 13:42:37 mysql01 Keepalived_vrrp[7283]: Script `chk_mysql` now returning 0
4月 09 13:42:37 mysql01 Keepalived_vrrp[7283]: VRRP_Script(chk_mysql) succeeded
4月 09 13:42:37 mysql01 Keepalived_vrrp[7283]: (VI_1) Changing effective priority from 70 to 120
4月 09 13:42:38 mysql01 Keepalived_vrrp[7283]: (VI_1) received lower priority (100) advert from 192.168.154.222 - discarding
4月 09 13:42:39 mysql01 Keepalived_vrrp[7283]: (VI_1) received lower priority (100) advert from 192.168.154.222 - discarding
4月 09 13:42:40 mysql01 Keepalived_vrrp[7283]: (VI_1) received lower priority (100) advert from 192.168.154.222 - discarding
4月 09 13:42:41 mysql01 Keepalived_vrrp[7283]: (VI_1) Entering MASTER STATE
4月 09 13:43:13 mysql01 Keepalived_vrrp[7283]: Script `chk_mysql` now returning 2

7.6 查看VIP ​

sh
jack@mysql01 $ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host noprefixroute 
       valid_lft forever preferred_lft forever
2: enp3s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
    link/ether f4:6b:8c:8c:3a:e4 brd ff:ff:ff:ff:ff:ff
3: wlp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether e0:0a:f6:ab:9e:bf brd ff:ff:ff:ff:ff:ff
    inet 192.168.154.221/24 brd 192.168.154.255 scope global noprefixroute wlp2s0
       valid_lft forever preferred_lft forever
    inet 192.168.154.220/32 scope global wlp2s0
       valid_lft forever preferred_lft forever
    inet6 fe80::6da0:ef0d:1f2a:4474/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever

可以看到wlp2s0网卡上面附带了192.168.154.220的虚拟IP地址。

7.7 测试 ​

使用vip连接数据库：
Alt text 关闭mysql01数据库：

sh
jack@mysql01:~$  sudo systemctl stop mysql

再次查看vip连接的数据库：
Alt text 同时查看虚拟ip，发现已经挂在了mysql02上面：

sh
jack@mysql02:~$ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host noprefixroute 
       valid_lft forever preferred_lft forever
2: enp3s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
    link/ether f4:6b:8c:87:ff:a6 brd ff:ff:ff:ff:ff:ff
3: wlo1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 84:7b:57:20:d4:60 brd ff:ff:ff:ff:ff:ff
    altname wlp0s20f3
    inet 192.168.154.222/24 brd 192.168.154.255 scope global noprefixroute wlo1
       valid_lft forever preferred_lft forever
    inet 192.168.154.220/32 scope global wlo1
       valid_lft forever preferred_lft forever
    inet6 fe80::e3d6:8b35:d16b:a9d/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever

8. 常见报错 ​

8.1 slave同步报错 ​

  1. 报错内容为Coordinator stopped because there were error(s) in the worker(s). The most recent failure being: Worker 1 failed executing transaction 'd175300f-13d0-11f0-a3cd-000c2938bad6:1' at source log mysql-bin.000003, end_log_pos 480. See error log and/or performance_schema.replication_applier_status_by_worker table for more details about this failure or others, if any. gtid方式主从数据不一致，同步数据时报错。
    解决办法-跳过事务:
sh
mysql> select * from performance_schema.replication_applier_status_by_worker\G
*************************** 1. row ***************************
                                           CHANNEL_NAME: 
                                              WORKER_ID: 1
                                              THREAD_ID: NULL
                                          SERVICE_STATE: OFF
                                      LAST_ERROR_NUMBER: 1396
                                     LAST_ERROR_MESSAGE: Worker 1 failed executing transaction 'd175300f-13d0-11f0-a3cd-000c2938bad6:1' at source log mysql-bin.000002, end_log_pos 476; Error 'Operation ALTER USER failed for 'root'@'localhost'' on query. Default database: ''. Query: 'ALTER USER 'root'@'localhost' IDENTIFIED WITH 'caching_sha2_password' AS '$A$005$AgA    D(WvJik>{9Jxgk3DXenY5A0zz1lrkRRNv6Wmye3EXI/iqfTj6ZfYA''
                                   LAST_ERROR_TIMESTAMP: 2025-04-09 07:54:41.866266
                               LAST_APPLIED_TRANSACTION: 
     LAST_APPLIED_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP: 0000-00-00 00:00:00.000000
    LAST_APPLIED_TRANSACTION_IMMEDIATE_COMMIT_TIMESTAMP: 0000-00-00 00:00:00.000000
         LAST_APPLIED_TRANSACTION_START_APPLY_TIMESTAMP: 0000-00-00 00:00:00.000000
           LAST_APPLIED_TRANSACTION_END_APPLY_TIMESTAMP: 0000-00-00 00:00:00.000000
                                   APPLYING_TRANSACTION: d175300f-13d0-11f0-a3cd-000c2938bad6:1
         APPLYING_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP: 2025-04-08 00:55:05.289325
        APPLYING_TRANSACTION_IMMEDIATE_COMMIT_TIMESTAMP: 2025-04-08 00:55:05.289325
             APPLYING_TRANSACTION_START_APPLY_TIMESTAMP: 2025-04-09 07:54:41.863571
                 LAST_APPLIED_TRANSACTION_RETRIES_COUNT: 0
   LAST_APPLIED_TRANSACTION_LAST_TRANSIENT_ERROR_NUMBER: 0
  LAST_APPLIED_TRANSACTION_LAST_TRANSIENT_ERROR_MESSAGE: 
LAST_APPLIED_TRANSACTION_LAST_TRANSIENT_ERROR_TIMESTAMP: 0000-00-00 00:00:00.000000
                     APPLYING_TRANSACTION_RETRIES_COUNT: 0
       APPLYING_TRANSACTION_LAST_TRANSIENT_ERROR_NUMBER: 0
      APPLYING_TRANSACTION_LAST_TRANSIENT_ERROR_MESSAGE: 
    APPLYING_TRANSACTION_LAST_TRANSIENT_ERROR_TIMESTAMP: 0000-00-00 00:00:00.000000
*************************** 2. row ***************************
                                           CHANNEL_NAME: 
                                              WORKER_ID: 2
                                              THREAD_ID: NULL
                                          SERVICE_STATE: OFF
                                      LAST_ERROR_NUMBER: 0
                                     LAST_ERROR_MESSAGE: 
                                   LAST_ERROR_TIMESTAMP: 0000-00-00 00:00:00.000000
                               LAST_APPLIED_TRANSACTION: 
     LAST_APPLIED_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP: 0000-00-00 00:00:00.000000
    LAST_APPLIED_TRANSACTION_IMMEDIATE_COMMIT_TIMESTAMP: 0000-00-00 00:00:00.000000
         LAST_APPLIED_TRANSACTION_START_APPLY_TIMESTAMP: 0000-00-00 00:00:00.000000
           LAST_APPLIED_TRANSACTION_END_APPLY_TIMESTAMP: 0000-00-00 00:00:00.000000
                                   APPLYING_TRANSACTION: 
         APPLYING_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP: 0000-00-00 00:00:00.000000
        APPLYING_TRANSACTION_IMMEDIATE_COMMIT_TIMESTAMP: 0000-00-00 00:00:00.000000
             APPLYING_TRANSACTION_START_APPLY_TIMESTAMP: 0000-00-00 00:00:00.000000
                 LAST_APPLIED_TRANSACTION_RETRIES_COUNT: 0
   LAST_APPLIED_TRANSACTION_LAST_TRANSIENT_ERROR_NUMBER: 0
  LAST_APPLIED_TRANSACTION_LAST_TRANSIENT_ERROR_MESSAGE: 
LAST_APPLIED_TRANSACTION_LAST_TRANSIENT_ERROR_TIMESTAMP: 0000-00-00 00:00:00.000000
                     APPLYING_TRANSACTION_RETRIES_COUNT: 0
       APPLYING_TRANSACTION_LAST_TRANSIENT_ERROR_NUMBER: 0
      APPLYING_TRANSACTION_LAST_TRANSIENT_ERROR_MESSAGE: 
    APPLYING_TRANSACTION_LAST_TRANSIENT_ERROR_TIMESTAMP: 0000-00-00 00:00:00.000000
*************************** 3. row ***************************
                                           CHANNEL_NAME: 
                                              WORKER_ID: 3
                                              THREAD_ID: NULL
                                          SERVICE_STATE: OFF
                                      LAST_ERROR_NUMBER: 0
                                     LAST_ERROR_MESSAGE: 
                                   LAST_ERROR_TIMESTAMP: 0000-00-00 00:00:00.000000
                               LAST_APPLIED_TRANSACTION: 
     LAST_APPLIED_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP: 0000-00-00 00:00:00.000000
    LAST_APPLIED_TRANSACTION_IMMEDIATE_COMMIT_TIMESTAMP: 0000-00-00 00:00:00.000000
         LAST_APPLIED_TRANSACTION_START_APPLY_TIMESTAMP: 0000-00-00 00:00:00.000000
           LAST_APPLIED_TRANSACTION_END_APPLY_TIMESTAMP: 0000-00-00 00:00:00.000000
                                   APPLYING_TRANSACTION: 
         APPLYING_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP: 0000-00-00 00:00:00.000000
        APPLYING_TRANSACTION_IMMEDIATE_COMMIT_TIMESTAMP: 0000-00-00 00:00:00.000000
             APPLYING_TRANSACTION_START_APPLY_TIMESTAMP: 0000-00-00 00:00:00.000000
                 LAST_APPLIED_TRANSACTION_RETRIES_COUNT: 0
   LAST_APPLIED_TRANSACTION_LAST_TRANSIENT_ERROR_NUMBER: 0
  LAST_APPLIED_TRANSACTION_LAST_TRANSIENT_ERROR_MESSAGE: 
LAST_APPLIED_TRANSACTION_LAST_TRANSIENT_ERROR_TIMESTAMP: 0000-00-00 00:00:00.000000
                     APPLYING_TRANSACTION_RETRIES_COUNT: 0
       APPLYING_TRANSACTION_LAST_TRANSIENT_ERROR_NUMBER: 0
      APPLYING_TRANSACTION_LAST_TRANSIENT_ERROR_MESSAGE: 
    APPLYING_TRANSACTION_LAST_TRANSIENT_ERROR_TIMESTAMP: 0000-00-00 00:00:00.000000
*************************** 4. row ***************************
                                           CHANNEL_NAME: 
                                              WORKER_ID: 4
                                              THREAD_ID: NULL
                                          SERVICE_STATE: OFF
                                      LAST_ERROR_NUMBER: 0
                                     LAST_ERROR_MESSAGE: 
                                   LAST_ERROR_TIMESTAMP: 0000-00-00 00:00:00.000000
                               LAST_APPLIED_TRANSACTION: 
     LAST_APPLIED_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP: 0000-00-00 00:00:00.000000
    LAST_APPLIED_TRANSACTION_IMMEDIATE_COMMIT_TIMESTAMP: 0000-00-00 00:00:00.000000
         LAST_APPLIED_TRANSACTION_START_APPLY_TIMESTAMP: 0000-00-00 00:00:00.000000
           LAST_APPLIED_TRANSACTION_END_APPLY_TIMESTAMP: 0000-00-00 00:00:00.000000
                                   APPLYING_TRANSACTION: 
         APPLYING_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP: 0000-00-00 00:00:00.000000
        APPLYING_TRANSACTION_IMMEDIATE_COMMIT_TIMESTAMP: 0000-00-00 00:00:00.000000
             APPLYING_TRANSACTION_START_APPLY_TIMESTAMP: 0000-00-00 00:00:00.000000
                 LAST_APPLIED_TRANSACTION_RETRIES_COUNT: 0
   LAST_APPLIED_TRANSACTION_LAST_TRANSIENT_ERROR_NUMBER: 0
  LAST_APPLIED_TRANSACTION_LAST_TRANSIENT_ERROR_MESSAGE: 
LAST_APPLIED_TRANSACTION_LAST_TRANSIENT_ERROR_TIMESTAMP: 0000-00-00 00:00:00.000000
                     APPLYING_TRANSACTION_RETRIES_COUNT: 0
       APPLYING_TRANSACTION_LAST_TRANSIENT_ERROR_NUMBER: 0
      APPLYING_TRANSACTION_LAST_TRANSIENT_ERROR_MESSAGE: 
    APPLYING_TRANSACTION_LAST_TRANSIENT_ERROR_TIMESTAMP: 0000-00-00 00:00:00.000000
4 rows in set (0.01 sec)

mysql>  stop slave;
Query OK, 0 rows affected, 1 warning (0.01 sec)

mysql> set @@session.gtid_next='d175300f-13d0-11f0-a3cd-000c2938bad6:1';
Query OK, 0 rows affected (0.00 sec)

mysql>  begin;commit;
Query OK, 0 rows affected (0.00 sec)

Query OK, 0 rows affected (0.00 sec)

mysql> set @@session.gtid_next=automatic;
Query OK, 0 rows affected (0.00 sec)

mysql> start slave;
Query OK, 0 rows affected, 1 warning (0.04 sec)