首先本次线上故障处理解决,衷心感谢知数堂助教导师:田帅萌(田导师),其次是知数堂的所有老师及成员。在帮我分析问题。本人也由衷的表示感谢。
事件回顾:
- 数据库架构:
数据库版本 : percona MySQL5.7.22
主从同步方式:GTID 模式 + 半同步
由于一次数据库配置文件问题导致主数据库挂掉,自动切换到从数据库[slave-01]。所导致主数据库降级为从数据。所以一直在调整配置降级的master并且没有对外提供服务,但是主从一直保持同步。
这也是事故的开始,由于开发需要一个能够远程连接数据库的账号,为了安全期间我每次等开发用完都会手动删除掉用户,由于主库降级,一时大意看错了服务信息,我就在降级的主数据库执行了删除数据库账户,至此导致数据库主从同步异常。
- 现在的数据库架构
graph TD
slave-01 --drop user--> master;
slave-01 --> slave-02
当时第一想法,赶紧把它跟从线上负载中切掉,以免影响服务正常运行,但是看到没有加入到负载我就放心了,由于没有处理这个问题的经验,直接就把从的数据库给格式化了,重新在主数据库打包,并推送到故障从库中并导入,然后执行change master。
- 在从库误插入数据报错信息
show slave status \G
Coordinator stopped because there were error(s) in the worker(s). The most recent failure being: Worker 1 failed executing transaction ’53a2cd85-8b40-11e8-9a04-44a8423df7f3:375319′ at master log beitou_23306_bin.000070, end_log_pos 199148929. See error log and/or performance_schema.replication_applier_status_by_worker table for more details about this failure or others, if any.
- 处理流程图:
graph LR
mysqldump导出 --> scp推送从数据库
scp推送从数据库--> slave数据库导入并执行changemaster
- 执行完change master 如下报错:
show slave status \G
Last_IO_Errno: 1236
Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: ‘The slave is connecting using CHANGE MASTER TO MASTER_AUTO_POSITION = 1, but the master has purged binary logs containing GTIDs that the slave requires.’
通过田导师的指导处理流程如下:
- 主数据库:
备份导出:
mysqldump --single-transaction --master-data=2 --triggers --routines --all-databases \
-uroot -proot -S /data/mysql_3306_beitou/run/mysql_3306_beitou.sock > /opt/master_all.sql
推送到从服务器:
scp master_all.sql 192.168.0.1:~
- 从数据库
将数据导入到从数据库:
mysql -uroot -pxxxxx -f -S /data/mysql_3306_beitou/run/mysql_3306_beitou.sock < /root/master_all.sql
查看SET @@GLOBAL.GTID_PURGED的信息并记录下来
head -n 40 master_all.sql
进入从 MySQL shell
执行reset master 及执行刚才记录的SET @@GLOBAL.GTID_PURGED的信息
resert master;
SET @@GLOBAL.GTID_PURGED='49394688-8b40-11e8-a72d-1418776181b3:1-698298,
53a2cd85-8b40-11e8-9a04-44a8423df7f3:1-427145';
再次执行change master
CHANGE MASTER TO
MASTER_HOST='192.168.0.2',
MASTER_USER='sync',
MASTER_PASSWORD='xxxxxx',
MASTER_AUTO_POSITION = 1;
启动start slave
start slave;
查看状态
show slave status \G
神奇的一刻发生了:
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
- 中间执行change master 碰到问题如下:
ERROR 1201 (HY000): Could not initialize master info structure; more error messages can be found in the MySQL error log
解决方法:
reset slave all;
- 最后总结:
根据田导师分析 主从配置失败的原因是构建主从的时候 没有在从库执行 resert master;