这个专题讲一些MySQL日常运维的异常处理

1. 现象

一套MySQL主从复制出现异常

start slave 时报错

 [ERROR] Error running query, slave SQL thread aborted. Fix the problem, and restart the slave SQL thread with "SLAVE START". We stopped at log 'mysql-bin.000077' position 1027952423.  

2. 原因查找

2.1 查看error日志

首先我们查看error日志

发现如下报错

[ERROR] Slave SQL for channel '': Could not execute Write_rows event on 
table safe.safelog; Duplicate entry '6101370' for key 'PRIMARY', 
Error_code: 1062; handler error HA_ERR_FOUND_DUPP_KEY; the event's 
master log mysql-bin.000077, end_log_pos 1027953607, Error_code: 1062

可以看到报错原因为主键冲突

2.2 查看复制状态

我们执行

show slave status\G

可以看出是同样的报错

2.3 继续分析

一般这种情况是从库没有设置只读，检查过已经设置为只读

同时确认了该重复值在开始复制前就已存在，所以可能为复制的起始点错误导致

备份主库时一般使用mysqldump命令 加上--master-data参数可得到起始点

该主从使用的是innobackupex 工具

备份

innobackupex --parallel=16 --throttle=4000  --user=root --password=XXXX --slave-info    /data/

还原

innobackupex  --defaults-file=/etc/my.cnf    --apply-log     /data/2019-01-24_13-56-05

innobackupex  --defaults-file=/etc/my.cnf    --copy-back    /data/2019-01-24_13-56-05

使用的复制起始点是 xtrabackup_binlog_pos_innodb 文件的内容

cat  xtrabackup_binlog_pos_innodb

mysql-bin.000077        1027950562

一切看起来都设正常的，问题出在哪里呢

3. 问题解决

上面获取复制点的 xtrabackup_binlog_pos_innodb 文件引起了注意

一般我们用的xtrabackup_binlog_info 这个文件

这2个文件有什么区别呢

xtrabackup_binlog_pos_innodb 只记录innodb引擎的变化，而不会记录其他的引擎

接下来我们查询这2个文件的信息是否相同

最后发现xtrabackup_binlog_info的值要略大于xtrabackup_binlog_pos_innodb的值

这时原因找到了 是由于该数据库同时还有MyISAM引擎的表导致这2个文件的值不相同

最后我们使用xtrabackup_binlog_info里面的值，复制正常

5. 参考链接

https://blog.51cto.com/jschu/1704848

https://www.percona.com/doc/percona-xtrabackup/2.3/howtos/setting_up_replication.html