MySQL主从配置-之GTID中途服务故障【第三篇】

• 没有实操过MySQL主从复制的，请参考文章：MySQL主从-GTID复制

现在模拟一个主从复制架构中，从服务器运行期间出现故障，导致不再同步主服务器的场景，并要求不能暂停线上业务，进行数据同步修复，恢复一致。

• 主库还在陆续插入，此时模拟slave节点宕机或异常

在此就直接执行：stop slave; 

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

• 开始从库恢复数据

 思路：

1. 先通过mysqldump全量备份当前的数据，由于不能影响业务，所以在mysqldump数据时不能造成锁表。要保持数据写入。
2. 由于mysqldump时数据还在写入，所以有一部分数据还是会同步不全，所以导入mysqldump的数据后，跳过dump中包含的GTID事务，再重新建立一次主从配置，开启slave线程，恢复数据并同步。

操作：

• mysqldump不锁表备份数据

mysqldump -u [数据库用户] -p [数据库密码] --single-transaction --master-data=2 -R [要备份的数据库名称] | gzip > dump.sql

重点参数：--single-transaction

• 查看当前mysqldump导出数据的GTID号

grep GLOBAL.GTID_PURGED dump.sql

显示结果：ae0a8ec4-6fc1-11e9-821a-4ccc6a4d7344:1-902 表示master执行到的GTID事务号。

• 去从数据库导入dump.sql文件

导入dump.sql文件时就会提示错误：只能在@@GLOBAL时设置。GTID_EXECUTED为空

can only be set when @@GLOBAL.GTID_EXECUTED is empty

要想跳过某些GTID，slave必须保证 gtid_purged 参数为空才能正确跳过。

• 查看slave当前的gtid_purged

show global variables like '%gtid%';

mysql> show global variables like '%gtid%';
+----------------------------------+-------------------------------------------------------------------------------------+
| Variable_name                    | Value                                                                               |
+----------------------------------+-------------------------------------------------------------------------------------+
| binlog_gtid_simple_recovery      | ON                                                                                  |
| enforce_gtid_consistency         | ON                                                                                  |
| gtid_executed                    | b30cb2ff-32d4-11eb-a447-000c292826bc:1-2,
c9fba9e2-db3b-11eb-81d4-000c298d8da1:1-80 |
| gtid_executed_compression_period | 1000                                                                                |
| gtid_mode                        | ON                                                                                  |
| gtid_owned                       |                                                                                     |
| gtid_purged                      | c9fba9e2-db3b-11eb-81d4-000c298d8da1:1-70                                           |
| session_track_gtids              | OFF                                                                                 |
+----------------------------------+-------------------------------------------------------------------------------------+
8 rows in set (0.02 sec)

• 当前gtid_purged不为空，执行：

mysql> reset master;
Query OK, 0 rows affected (0.05 sec)
 
mysql> show global 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_owned                       |       |
| gtid_purged                      |       |
| session_track_gtids              | OFF   |
+----------------------------------+-------+
8 rows in set (0.00 sec)

• gtid_purged为空后，开始重置slave

mysql> stop slave;
Query OK, 0 rows affected (0.00 sec)
 
mysql> reset slave all;
Query OK, 0 rows affected (0.02 sec)

• 重置后，设置跳过的GTID，并重新同步master

mysql> SET @@GLOBAL.GTID_PURGED='c9fba9e2-db3b-11eb-81d4-000c298d8da1:1-228';
Query OK, 0 rows affected (0.01 sec)
 
mysql> CHANGE MASTER TO MASTER_HOST='主库IP地址',MASTER_USER='主库用户名',MASTER_PASSWORD='主库密码',MASTER_PORT=3306,MASTER_AUTO_POSITION=1;
Query OK, 0 rows affected, 2 warnings (0.04 sec)

• 开启SLAVE进程，查看同步状态

mysql> start slave;
Query OK, 0 rows affected (0.01 sec)

mysql> show slave status\G

操作完成以后，就可以看到主从恢复了。