5.7 并行复制配置 基于GTID 搭建中从 基于GTID的备份与恢复，同步中断处理
这个文章包含三个部分
1：gtid的多线程复制
2：同步中断处理
3：GTID的备份与恢复

下面文字相关的东西 大部分都比较重要，可以看一下
master: 192.168.17.21
slave: 192.168.17.22
salve: 192.168.17.23

分别在这三个机器上面安装 编译安装mysql 5.7
不会安装的话 这有安装脚本 https://www.cnblogs.com/noel/p/10314125.html
稍微注意一点 三个机器用不同的server_id 主库和从库里面的配置稍微有一点区别，在配置文件里面已标注。

下面是一些基础定于，用于后面更好的理解 changge master；
gtid_executed
在当前实例上执行过的GTID集合; 实际上包含了所有记录到binlog中的事务。所以，设置set sql_log_bin=0后执行的事务不会生成binlog 事件，也不会被记录到gtid_executed中。执行RESET MASTER可以将该变量置空。
gtid_purged
binlog不可能永远驻留在服务上，需要定期进行清理(通过expire_logs_days可以控制定期清理间隔)，否则迟早它会把磁盘用尽。gtid_purged用于记录已经被清除了的binlog事务集合，它是gtid_executed的子集。只有gtid_executed为空时才能手动设置该变量，此时会同时更新gtid_executed为和gtid_purged相同的值。gtid_executed为空意味着要么之前没有启动过基于GTID的复制，要么执行过RESET MASTER。执行RESET MASTER时同样也会把gtid_purged置空，即始终保持gtid_purged是gtid_executed的子集。
gtid_next
会话级变量，指示如何产生下一个GTID。可能的取值如下:
1）AUTOMATIC：
自动生成下一个GTID，实现上是分配一个当前实例上尚未执行过的序号最小的GTID。

2）ANONYMOUS：
设置后执行事务不会产生GTID。

3）显式指定的GTID：
可以指定任意形式合法的GTID值，但不能是当前gtid_executed中的已经包含的GTID，否则，下次执行事务时会报错。

GTID的生成受gtid_next控制。 在Master上，gtid_next是默认的AUTOMATIC,即在每次事务提交时自动生成新的GTID。它从当前已执行的GTID集合（即gtid_executed）中，找一个大于0的未使用的最小值作为下个事务GTID。同时在binlog的实际的更新事务事件前面插入一条set gtid_next事件。
在Slave上回放主库的binlog时，先执行set gtid_next ...，然后再执行真正的insert语句，确保在主和备上这条insert对应于相同的GTID。
一般情况下，GTID集合是连续的，但使用多线程复制(MTS)以及通过gtid_next进行人工干预时会导致gtid空洞。
继续执行事务，MySQL会分配一个最小的未使用GTID，也就是从出现空洞的地方分配GTID，最终会把空洞填上。
GTID相关的信息存储在binlog文件中
Previous_gtids_log_event 在每个binlog文件的开头部分，记录在该binlog文件之前已执行的GTID集合。
Gtid_log_event 即前面看到的set gtid_next ...,它出现在每个事务的前面，表明下一个事务的gtid
MySQL服务器启动时，通过读binlog文件，初始化gtid_executed和gtid_purged,使它们的值能和上次MySQL运行时一致。

gtid_executed被设置为最新的binlog文件中Previous_gtids_log_event和所有Gtid_log_event的并集。

gtid_purged为最老的binlog文件中Previous_gtids_log_event。

查看主从库之间是否开启了GTId
show variables like '%gtid_%';
mysql> show variables like '%gtid%';
+----------------------------------+------------------------------------------+
| Variable_name | Value |
+----------------------------------+------------------------------------------+
| binlog_gtid_simple_recovery | ON |
| enforce_gtid_consistency | ON |
| gtid_executed | |
| gtid_executed_compression_period | 1000 |
| gtid_mode | ON |
| gtid_next | AUTOMATIC |
| gtid_owned | |
| gtid_purged | 1907b4b1-18e9-11e9-8a38-000c29116902:1-2 |
| session_track_gtids | OFF |
+----------------------------------+------------------------------------------+
9 rows in set (0.00 sec)

检查从库配置文件 这几个参数是否加好：
slave-parallel-type=LOGICAL_CLOCK
slave-parallel-workers=16 ###自己定义大小
master_info_repository=TABLE
relay_log_info_repository=TABLE
relay_log_recovery=ON

在主库上面给从库授权

grant replication slave on *.* to 'repl'@'192.168.17.22' identfified by 'repl';
grant replication slave on *.* to 'repl'@'192.168.17.23' identfified by 'repl';
flush privileges;

在从库 22，23 上面分别执行一下语句。

CHANGE MASTER TO MASTER_HOST='192.168.17.21',MASTER_USER='repl',MASTER_PASSWORD='repl',MASTER_AUTO_POSITION=1;

##为什么不需要 找binlog 日志并称和pos 点：

在MASTER_AUTO_POSITION = 1的情况下 ，MySQL会使用 COM_BINLOG_DUMP_GTID 协议进行复制。过程如下：
备库发起复制连接时，将自己的已接受和已执行的gtids的并集(后面称为slave_gtid_executed)发送给主库。
主库将自己的gtid_executed与slave_gtid_executed的差集的binlog发送给Slave。主库的binlog dump过程如下：
检查slave_gtid_executed是否是主库gtid_executed的子集，如否那么主备数据可能不一致，报错。
检查主库的purged_executed是否是slave_gtid_executed的子集，如否代表缺失备库需要的binlog,报错
从最后一个Binlog开始扫描，获取文件头部的PREVIOUS_GTIDS_LOG_EVENT，如果它是slave_gtid_executed的子集，则这是需要发送给Slave的第一个binlog文件，否则继续向前扫描。
从第3步找到的binlog文件的开头读取binlog记录，判断binlog记录是否已被包含在slave_gtid_executed中，如果已包含跳过不发送。
从上面的过程可知，在指定MASTER_AUTO_POSITION = 1时，Master发送哪些binlog记录给Slave，取决于Slave的gtid_executed和Retrieved_Gtid_Set以及Master的gtid_executed，和relay_log_info以及master_log_info中保存的复制位点没有关系。

修复复制错误：

https://blog.csdn.net/leshami/article/details/52778480 这个里面也记录了一些常见的错误

修复复制错误是dba 经常需要做的一件事情，做成的原因有很多 这里就不一一描述了
在基于GTID的复制拓扑中，要想修复Slave的SQL线程错误，过去的SQL_SLAVE_SKIP_COUNTER方式不再适用。
需要通过设置gtid_next或gtid_purged完成，当然前提是已经确保主从数据一致，仅仅需要跳过复制错误让复制继续下去。

先在主库上面建立一个新的database learn
create database learn default character set utf8;
在从库72上面见一个表t
mysql> use learn;
Database changed
mysql> create table t(id int primary key auto_increment,name varchar(30));
Query OK, 0 rows affected (0.01 sec)
在主库上面建表 t；

mysql> use learn;
Database changed
mysql> create table t(id int primary key auto_increment,name varchar(30));
Query OK, 0 rows affected (0.01 sec)

mysql>
由于从库上这个表已经存在，从库72的复制SQL线程出错停止。
mysql> show slave status \G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 192.168.17.21
Master_User: repl
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000004
Read_Master_Log_Pos: 741
Relay_Log_File: relay-bin.000008
Relay_Log_Pos: 747
Relay_Master_Log_File: mysql-bin.000004
Slave_IO_Running: Yes
Slave_SQL_Running: No
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table: mysql.%,test.%
Last_Errno: 1050
Last_Error: Coordinator stopped because there were error(s) in the worker(s). The most recent failure being: Worker 1 failed executing transaction 'fba5d191-13ed-11e9-9bee-000c29f3cfeb:18' at master log mysql-bin.000004, end_log_pos 741. See error log and/or performance_schema.replication_applier_status_by_worker table for more details about this failure or others, if any.
Skip_Counter: 0
Exec_Master_Log_Pos: 534
Relay_Log_Space: 1242
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: NULL
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 1050
Last_SQL_Error: Coordinator stopped because there were error(s) in the worker(s). The most recent failure being: Worker 1 failed executing transaction 'fba5d191-13ed-11e9-9bee-000c29f3cfeb:18' at master log mysql-bin.000004, end_log_pos 741. See error log and/or performance_schema.replication_applier_status_by_worker table for more details about this failure or others, if any.
Replicate_Ignore_Server_Ids:
Master_Server_Id: 100
Master_UUID: fba5d191-13ed-11e9-9bee-000c29f3cfeb
Master_Info_File: mysql.slave_master_info
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State:
Master_Retry_Count: 86400
Master_Bind:
Last_IO_Error_Timestamp:
Last_SQL_Error_Timestamp: 190208 00:05:21
Master_SSL_Crl:
Master_SSL_Crlpath:
Retrieved_Gtid_Set: fba5d191-13ed-11e9-9bee-000c29f3cfeb:1-18
Executed_Gtid_Set: 084bf09c-18dc-11e9-b043-000c29e4e4c0:1-5,
fba5d191-13ed-11e9-9bee-000c29f3cfeb:1-17
Auto_Position: 1
Replicate_Rewrite_DB:
Channel_Name:
Master_TLS_Version:
1 row in set (0.00 sec)

mysql>
从上面的错误输出可以开出来 从库已经执行过的事务是'084bf09c-18dc-11e9-b043-000c29e4e4c0:1-5',执行出错的事务是'fba5d191-13ed-11e9-9bee-000c29f3cfeb:18'，当前主备的数据其实是一致的，可以通过设置gtid_next跳过这个出错的事务。
mysql> set gtid_next='fba5d191-13ed-11e9-9bee-000c29f3cfeb:18';
Query OK, 0 rows affected (0.00 sec)

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

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

mysql> set gtid_next='AUTOMATIC';
Query OK, 0 rows affected (0.00 sec)

mysql> start slave;
Query OK, 0 rows affected (0.06 sec)
当然也可以跳过多个事物 假如主从都执行了 几个事物 都成功了 ，数据已经一致了 只不过主从中断了
在可以在从库上面
reset master；
set global gtid_purged='fba5d191-13ed-11e9-9bee-000c29f3cfeb:1-18'
此时从库的Executed_Gtid_Set已经包含了主库上'1-18'的事务，再开启复制会从后面的事务开始执行，就不会出错了。
mysql> start slave;

Query OK, 0 rows affected (0.01 sec)

使用gtid_next和gtid_purged修复复制错误的前提是，跳过那些事务后仍可以确保主备数据一致。如果做不到，就要考虑pt-table-sync或者拉备份的方式了。

GTID与备份恢复

现在流行的备份方式有两种 mysqldump 和innobackupex 别的付费的不再讨论的范围内；
1、通过mysqldump进行备份
通过mysqldump做一个全量备份：
[root@node1 ~]# mysqldump --all-databases --single-transaction --routines --events --host=127.0.0.1 --port=3306 --user=root > dump.sql
生成的dump.sql文件里包含了设置gtid_purged的语句

SET @MYSQLDUMP_TEMP_LOG_BIN = @@SESSION.SQL_LOG_BIN;
SET @@SESSION.SQL_LOG_BIN= 0;
SET @@GLOBAL.GTID_PURGED='e10c75be-5c1b-11e6-ab7c-000c296078ae:1-10';
SET @@SESSION.SQL_LOG_BIN = @MYSQLDUMP_TEMP_LOG_BIN;
恢复数据前需要先通过reset master清空gtid_executed变量
[root@node2 ~]# mysql -h127.1 -e 'reset master'
[root@node2 ~]# mysql -h127.1 <dump.sql
否则执行设置GTID_PURGED的SQL时会报下面的错误
ERROR 1840 (HY000) at line 24: @@GLOBAL.GTID_PURGED can only be set when @@GLOBAL.GTID_EXECUTED is empty.
此时恢复出的MySQL实例的GTID_EXECUTED和备份时点一致：
由于恢复出的MySQL实例已经被设置了正确的GTID_EXECUTED，以master_auto_postion = 1的方式CHANGE MASTER到原来的主节点即可开始复制。
CHANGE MASTER TO MASTER_HOST='node1', MASTER_USER='repl', MASTER_PASSWORD='repl', MASTER_AUTO_POSITION = 1
如果不希望备份文件中生成设置GTID_PURGED的SQL，可以给mysqldump传入--set-gtid-purged=OFF关闭。

2、通过Xtrabackup进行备份
相比mysqldump，Xtrabackup是效率更高并且被广泛使用的备份方式。使用Xtrabackup进行备份的举例如下。
通过Xtrabackup创一个全量备份（可以在Slave上创建备份，以避免对主库的性能冲击）
innobackupex --defaults-file=/usr/local/mysql/my.cnf --host=127.1 --user=root --password=mysql --no-timestamp --safe-slave-backup --slave-info /mysql/bak
应用日志
innobackupex --apply-log /mysql/bak
查看备份目录中的xtrabackup_binlog_info文件可以找到备份时已经执行过的gtids
[root@node2 ~]# cat /mysql/bak/xtrabackup_binlog_info
mysql_bin.000001 191 e10c75be-5c1b-11e6-ab7c-000c296078ae:1-10
由于备份时添加了”--slave-info”选项并且从Slave节点拉取的备份，所以会生成xtrabackup_slave_info文件，也可以从这个文件里查找建立复制的SQL语句。
[root@node2 ~]# cat /mysql/bak/xtrabackup_slave_info
SET GLOBAL gtid_purged='e10c75be-5c1b-11e6-ab7c-000c296078ae:1-10';
CHANGE MASTER TO MASTER_AUTO_POSITION=1
将备份文件传送到新的节点node3的/mysql/bak目录并恢复(如果直接把备份传输到数据目录了，这一步可以省略)。
[root@node3 ~]# innobackupex --defaults-file=/etc/my.cnf --copy-back /mysql/bak
启动MySQL。
[root@node3 ~]# mysqld --defaults-file=/home/mysql/etc/my.cnf --skip-slave-start &
如果是从Slave拉的备份，一定不能直接开启Slave复制，这时的gtid_executed是错误的。需要手动设置gtid_purged后再start slave
CHANGE MASTER TO MASTER_HOST='192.168.17.21',MASTER_USER='repl',MASTER_PASSWORD='repl',MASTER_AUTO_POSITION=1;
start slave;