配置MySQL 5.7基於GTID實現主從複製和使用percona-toolkit實現監控及數據校驗

1、GTID主從複製原理及相關概念：

一、GTID簡介：

GTID：Global Transaction ID，全局事務ID，是一個已提交事務的編號，而且是一個全局惟一的編號。MySQL 5.6版本以後在主從複製類型上新增了GTID複製。經過GTID保證了每一個在master節點上提交的事務在集羣中有一個惟一的ID，這種方式強化了數據庫的主從一致性、故障恢復及容錯能力。

二、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的主從複製構建方式。

三、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衝突。

四、GTID使用限制：

（1）不支持create table ... select語句

（2）不支持針對臨時表的操做，即create | drop temporary table

（3）不支持非事務存儲引擎（如：MyISAM）

（4）不支持sql_slave_skip_counter

五、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，而後再循環，直到找到爲止

2、準備工做（兩個節點都須要執行以下操做）：

一、演示環境：

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

二、關閉SELinux和firewalld

三、配置epel源

四、配置percona源：

# yum -y install https://repo.percona.com/yum/percona-release-latest.noarch.rpm

# yum repolist

# yum list | grep -i percona

五、配置服務器時間同步

六、配置主機名

七、配置/etc/hosts文件：

# vim /etc/hosts

192.168.1.143 node1

192.168.1.144 node2

3、安裝Percona Server，並配置GTID主從複製（如未特殊說明，兩個節點都須要執行以下操做）：

一、安裝Percona Server：# yum -y install Percona-Server-server-57

二、修改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中

三、初始化MySQL數據：# mysqld --initialize --user=mysql

備註：確保初始化前/var/lib/mysql目錄爲空，初始化完成後會在此目錄中生成各種文件

四、啓動MySQL服務：

# systemctl start mysqld.service

# ss -tunlp | grep mysqld

# systemctl enable mysqld.service

# systemctl status mysqld.service

五、查看root@localhost用戶的初始密碼：# grep password /var/log/mysqld.log

六、配置MySQL安全向導：# mysql_secure_installation

七、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文件中的內容一致

八、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文件

九、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線程中斷。

十、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;

十一、slave節點查看GTID相關信息：

mysql> show slave status\G

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

mysql> show variables like '%gtid%';

mysql> show processlist;

4、驗證GTID主從複製：

一、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;

二、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%';

5、新slave節點加入GTID主從複製（如未特殊說明，在new slave節點執行以下操做）：

一、演示環境：

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

二、關閉SELinux和firewalld、配置epel源、配置服務器時間同步、配置主機名

三、配置percona源：

# yum -y install https://repo.percona.com/yum/percona-release-latest.noarch.rpm

# yum repolist

# yum list | grep -i percona

四、三個節點配置/etc/hosts文件：

# vim /etc/hosts

192.168.1.143 node1

192.168.1.144 node2

192.168.1.145 node3

五、安裝Percona Server：# yum -y install Percona-Server-server-57

六、修改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

七、初始化MySQL數據：# mysqld --initialize --user=mysql

八、啓動MySQL服務：

# systemctl start mysqld.service

# ss -tunlp | grep mysqld

# systemctl enable mysqld.service

# systemctl status mysqld.service

九、查看root@localhost用戶的初始密碼：# grep password /var/log/mysqld.log

十、配置MySQL安全向導：# mysql_secure_installation

十一、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';

十二、master節點將all_2019-06-12.sql備份文件發送至new slave節點：

# scp -p /backup/all_2019-06-12.sql node3:/backup

1三、master節點在db數據庫的tb表中插入測試數據，模擬備份後的數據變更：

mysql> use db;

mysql> insert into tb(age) values(0),(100);

mysql> select * from tb;

mysql> show master status;

1四、new slave節點清空gtid_executed變量的值，並恢復數據：

# mysql -uroot -p -e 'reset master;'

# mysql -uroot -p < /backup/all_2019-06-12.sql

1五、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

1六、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;

1七、master節點查看GTID相關信息：

mysql> show master status;

mysql> show slave hosts;

mysql> show processlist;

1八、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;

1九、new slave節點查看測試數據：

mysql> use db;

mysql> select * from tb;

6、主從複製延遲的解決方案及並行複製：

一、主從複製延遲的可能緣由：

（1）MySQL主從複製原本就不是實時的，而是異步的，即master節點提交事務以後，slave節點才執行一遍

（2）在master節點上對沒有索引的大表的列進行delete或update操做

（3）slave節點的硬件配置沒有master節點好

（4）網絡抖動致使slave節點的I/O線程複製延遲

二、主從複製延遲的解決方案：

（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）避免讓數據庫進行各類大量運算，數據庫是用來存儲數據的，讓應用端多分擔些壓力，或經過緩存來完成

三、配置並行複製：

（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%';

7、主從複製的監控：

一、percona-toolkit工具集中的pt-heartbeat監控原理：

先在master節點指定數據庫中建立一張名爲heartbeat的表，表中有個時間戳字段ts，master節點pt-heartbeat的update線程會在指定時間間隔更新時間戳，而slave節點上的pt-heartbeat的monitor線程會檢查複製的心跳記錄，這個記錄就是master節點修改的時間戳，而後和當前系統時間進行比對，得出時間上的差別，差別值就是延遲的時間大小，因爲heartbeat表中有server_id字段，在監控某個slave節點的延遲時指定參考master節點的server_id便可。

二、全部節點安裝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

三、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;

四、全部slave節點執行命令：# pt-heartbeat --master-server-id=1 --monitor -D db -uroot -p123456

備註：中括號中的數值分別表明1m、5m和15m的平均值，上述執行結果表示沒有主從複製延遲

8、主從複製的數據校驗與修復：

一、主從複製的數據校驗、修復過程當中須要使用到的工具：

使用percona-toolkit工具集中的pt-table-checksum檢查主從節點數據的一致性，使用pt-table-sync修復不一致的數據信息。

二、pt-table-checksum校驗比對原理：

pt-table-checksum針對某張表中的全部字段進行hash函數運算，在master節點執行校驗查詢，把獲得的校驗值記錄爲master_crc、master_cnt，在slave節點也執行校驗查詢，把獲得的校驗值記錄爲this_crc、this_cnt，最後經過比對slave節點的this值和master節點master值來判斷主從之間的數據一致性，並輸出比對結果。

三、pt-table-sync同步數據原理：

pt-table-sync高效同步MySQL表之間的數據，能夠單向或雙向同步表數據，也能夠同步單個表，或同步整個數據庫，但不一樣步表結構、索引、或任何其它模式對象，因此在修復以前確保表存在。

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

五、全部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

六、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的表

七、全部節點查看db.checksums表的信息：

mysql> select * from db.checksums\G

備註：this_crc=master_crc、this_cnt=master_cnt

八、模擬主從表的數據不一致：

（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;

九、master節點校驗db數據庫的tb表信息：

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

備註：主從節點數據校驗和同步的前提條件是主從複製正常運行，此處出現主從表的數據不一致

十、slave節點查看db.checksums表的信息：

mysql> select * from db.checksums\G

備註：this_crc不等於master_crc、this_cnt不等於master_cnt

十一、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：指定須要執行同步的表，多個表之間用逗號分隔

十二、master節點修復主從表的不一致數據：

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

1三、master節點校驗db數據庫的tb表信息：

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

1四、slave節點查看db.checksums表的信息：

mysql> select * from db.checksums\G

備註：this_crc=master_crc、this_cnt=master_cnt

1五、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