线上环境MySQL Last_Errno：1292复制故障一例

GrowthDBA 2021-11-19

1171

这两天，又收到了MySQL线上环境的告警，其实上篇Troubleshooting文章线上环境MySQL复制延迟一例的截图就已经预告了今天的内容，今天的修复的过程比较简单，Let's GO。

问题的定位和处理

问题环境概况及部分参数

MySQL Version：10.1.10-MariaDBMySQL Port：3306同步方式：MIXED+binlog-position+异步复制报警所在的MySQL集群是一主两从架构，业务上线较早，使用的数据库版本也是MariaDB 10.1.10很早的版本。关键参数：binlog_format=MIXEDParallel_Mode: conservative

问题定位

show slave status\G;

把报错单独复制出来：

Last_SQL_Errno: 1292Last_SQL_Error: Error 'Incorrect datetime value: '' for column 'std_timeflag' at row 1' on query. Default database: '[database_name]'. Query: 'insert into [table_name] (id, fid, time_flag,  request_count, total_request_time, timeout_count,  ctime, std_timeflag)values (NULL, 149, '17/Nov/111121:23:11',  6838324, 5269145, 3163,  '2021-11-17 23:13:30.798000', '')'

从报错可以直观看到详细的错误信息：

Last_SQL_Error: Error 'Incorrect datetime value: '' for column 'std_timeflag' at row 1' on query.

从库在回放一条INSERT语句时报错，因为'std_timeflag'字段数据类型datetime错误，传输到从库中的该字段值为空，所以导致了主从同步中断。错误代码：1292。

问题处理

根据报错提示的信息，先到主库上查看是否有这条数据（添加多个查询条件的目的在于确保问题数据的唯一性）：

SELECT * FROM [database_name].[table_name] WHERE fid=149 AND request_count=6838324 AND total_request_time=5269145 AND timeout_count=3163;

查得出1条数据，同时，我们得到了主库上该行数据'id'、'std_timeflag'字段的值。

从库再次确认没有该数据，并停掉同步：

stop slave;

跳过该错误的binlog event（注意：GTID环境下不能使用这种方式跳过Event）：

SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1;

启动同步，并查看同步状态：

start slave;show slave status\G;

至此，同步状态恢复正常，Seconds_Behind_Master也在慢慢回落。

告警状态恢复正常。

手工处理主从不一致的数据

上一步骤，我们恢复了主从同步状态，但是主库要比从库多出1条数据，主从不一致，线上环境是不允许发生这种情况的。所以，我们需要手动将数据修复回来。

从库设置执行SQL不记录binlog，并手动INSERT失败的数据，还原执行SQL记录binlog设置：

set sql_log_bin=0;insert into [database_name].[table_name] (id, fid, time_flag, request_count, total_request_time, timeout_count, ctime, std_timeflag) values (1934455, 149, '17/Nov/111121:23:11', 6838324, 5269145, 3163, '2021-11-17 23:13:30.798000', '0000-00-00 00:00:00');set sql_log_bin=1;

查询数据，同时再次确认同步状态：

show slave status\G;

至此，修复工作全部完成。同步延迟的报警也关闭了。

小结

在MySQL 5.7以上版本的主从复制环境中，我还暂时没有遇到过这种因为错误字段类型导致的报错，此例的数据库版本是MariaDB 10.1.10，并且是基于MIXED+binlog-position+异步复制的同步方式，不同的版本可能遇到错误代码和报错都会存在差异，如果遇到此类报错，修复同步的方法差不多，总结一下：

一、恢复同步1、停止复制stop slave;2、跳过错误的binlog event（注意：此跳过方法只适用于非GTID复制方式的同步环境）SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1;3、启动复制。至此，同步状态恢复正常start slave;二、手动调整主从不一致的数据1、设置执行SQL不记录binlogset sql_log_bin=0;2、手动修复INSERT INTO ...;3、还原执行SQL不记录binlog设置set sql_log_bin=1;4、检查数据准确性、查验主从同步状态SELECT * FROM ...;show slave status\G;

最后希望此文可以当大家遇到类似问题时帮助到大家。每天进步一点点。

end

mysql

文章转载自 GrowthDBA，如果涉嫌侵权，请发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。

线上环境MySQL Last_Errno：1292复制故障一例

评论