一套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.
首先我们查看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
可以看到报错原因为主键冲突
我们执行
show slave status\G
可以看出是同样的报错
一般这种情况是从库没有设置只读,检查过已经设置为只读
同时确认了该重复值在开始复制前就已存在,所以可能为复制的起始点错误导致
备份主库时一般使用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
一切看起来都设正常的,问题出在哪里呢
上面获取复制点的 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里面的值,复制正常
https://blog.51cto.com/jschu/1704848
https://www.percona.com/doc/percona-xtrabackup/2.3/howtos/setting_up_replication.html