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