MySQL 从库Crash后重启时复制出错的问题
2019-08-07 本文已影响0人
斜不靠谱
背景
MySQL从库因为机器卡顿原因,重启机器,机器起来后需要重新启动从库
结果开启同步后报错
Last_SQL_Error: Could not execute Delete_rows event on table pay_gateway.tbl_accounting_notifyinfo; Can't find record in 'tbl_accounting_notifyinfo', Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND; the event's master log mysql-bin.003660, end_log_pos 66840371
原因分析
- 因为db复制情况的信息记录在relay log info、master info文件中(通过参数可以设置为文件,或者表)
公司master-info-repository = TABLE 、relay-log-info-repository = TABLE ,表分别为mysql.slave_master_info和 mysql.slave_relay_log_info
relay log :即读取过来的master 的binlog ,内容与格式与master 的binlog 一致
relay log info :记录SQL Thread 应用的relay log 的位置、文件号等信息
master info :记录IO Thread 读取master 的binlog 的位置、文件号、延迟等信息 - 因此当这三个文件如果不及时落地,则主机crash后会导致数据不一致(即使双一也会有问题,因为要考虑复制信息神马时候保存到表中)
- master info 与relay info 有如下3 个参数控制刷新:
| 参数 | 存储在FILE中 | 存储在table中 |
|---|---|---|
| sync_relay_log | 默认为10000 ,即每10000 次sync_relay_log events会刷新到磁盘(using fdatasync())。为0 则表示不刷新,交由OS 的cache 控制。大于0 则表示N个events写到Relay log后,刷到磁盘.IO线程复制到缓存后写入磁盘 | |
| sync_master_info | 当设置为0 ,则与events无关,由OS处理;如果大于0,则表示在sync_master_info次transactions后刷到磁盘,默认为10000 次刷新到磁盘 | 当设置为0 ,则表不做任何更新,设置为1 ,则每次事件会更新表 # 默认为10000 |
| sync_relay_log_info | 当设置为0 ,交由OS 刷新磁盘;如果大于0,则sync_relay_log_info次transactions后刷到磁盘.默认为10000 次刷新到磁盘 | INNODB 存储(支持事务),则无论为任何值,则都每次event 都会更新表(无论此参数值为多少)。 如果是非事务存储引擎,则为0时不更新表,大于0时则在N次events后更新.默认值都是10000 |
- 使用命令查看IO线程与SQL线程执行情况
mysql> select Master_log_name,Master_log_pos,'IO Thread 读取Master的positon' comments from mysql.slave_master_info
union select Master_log_name,Master_log_pos,'SQL Thread 执行Master的positon' comments from mysql.slave_relay_log_info;
- 导致复制出错的原因
在mysql意外crash的情况下,默认参数配置slave_relay_log_info记录的Master_log_name、Master_log_pos 要大于或等于 mysql.slave_master_info记录的Master_log_name、Master_log_pos
而重启复制后，IO线程拉主库binlog的postion是从slave_master_info记录的点开始的，会导致重复拉取
slave真正执行的点是slave_relay_log_info记录的点,由于重复拉取binlog，relay log会有重复，自然sql执行时会有冲突。
解决问题
- 修改参数配置 sync_relay_log = 1 sync_master_info = 1 sync_relay_log_info = 1,机器断电重启后DB复制正常,问题解决(但是会增加很大的负担)
- 跳过错误 change,或者设置skip_errors等
- 有个参数可以让mysql自动从最新的点开始同步
延伸问题
如果mysql.slave_master_info 的记录的点要比mysql. slave_relay_log_info点大 机器意外crash,重启后依然会有错误
问题分析
- SQL thread启动的位置和slave_relay_log_info 记录的位置一致(478386666) 。 IO thread 启动的位置由于mysql.slave_master_info 表记录被更新所以实际启动的点要大。
当db非正常关闭时,mysql.slave_master_info 表记录由于sync_master_info=10000 的设置导致部分event 信息没有记录到表中。
但是实际已经生成relay log 。那启动的时候IO Thread 是根据表中的记录开始启动IO ,这样就会导致没有记录到表中的relay log 被重复拉取了一次,SQL thread 重复应用
这段relay log 导致复制中断。那么这种问题是执行了重复拉取的一段relay log 导致主键冲突,跳过错误即可,并且数据不会丢失。
解决方法
- 设置sync_master_info=1 让表实时更新记录即可解决问题
- 手动重新change 一次也可避免复制中断
并且手动change 的点应该是按照mysql.slave_relay_log_info 表记录的点
为什么都是sql thread 都是同一个位置启动,为什么需要手动change 呢?
因为重新change 是会清空现有的relay log ,从指定位置重新拉取,而直接启动则是续写之前的relay log 。
解决方案汇总
- DB 复制正常关闭情况直接启动复制即可,如果非正常关闭则需要以mysql.slave_relay_log_info表记录的点重新change,记得一定要重新change,这样
可以清空之前生成的relay log重新拉取。 - 使用GTID复制,无需file、positon ,两张表中不会记录任何信息
- 设置参数为1,实时更新表记录。
sync_relay_log = 1
sync_master_info = 1 sync_relay_log_info = 1
master-info-repository = TABLE
relay-log-info-repository = TABLE - 每次启动check一下slave_master_info和slave_relay_log_info 记录的positon是否一致,如果不一致按照slave_relay_log_info的点重新change后重启复制,切记需要重新change
- 明白这种复制中断的原因,跳过即可。不推荐设置为全1,IO压力加大会导致性能瓶颈,从监控看从20飙到60,机器还是单实例、无业务流量的情景。
- 启动时加上 --relay-log-recovery 参数 ,会在server启动时新创建一个Relay log文件，并让SQL线程指向新的Relay log，让IO线程的位置指向SQL线程执行的master位置然后继续读取Master的binlog
