-
没有实操过MySQL主从复制的,请参考文章:MySQL主从-GTID复制
现在模拟一个主从复制架构中,从服务器运行期间出现故障,导致不再同步主服务器的场景,并要求不能暂停线上业务,进行数据同步修复,恢复一致。
-
主库还在陆续插入,此时模拟slave节点宕机或异常
在此就直接执行:stop slave;
mysql> stop slave; Query OK, 0 rows affected (0.01 sec)
-
开始从库恢复数据
思路:
- 先通过mysqldump全量备份当前的数据,由于不能影响业务,所以在mysqldump数据时不能造成锁表。要保持数据写入。
- 由于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
操作完成以后,就可以看到主从恢复了。