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

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

你可能感兴趣的:(mysql)