某业务数据库报表查询延时, 使用平台工具检测发现SQL THREAD数据应用进程处于not running状态，初步分析报错error 1062，是数据冗余引起的，是存在唯一键的列进行插入失败了，然后经过一系列操作，最终通过几个方法解决了这个问题，下面由我详细和大家分享一下，由于涉及到一些原理性操作，咱们先从技术本身原理分析一下。

先上一张主从原理图：

前提是使用行模式并且innodb引擎的情况，用户的插入、更新等操作会记录到binlog，在我们的从库会发起一个连接到主库，主库的binlog dump thread会把binlog发送到从库，从库的IO线程会接收这个主库日志写入到中继日志，再则从库的SQL应用线程从这个relay log读取内容写入到从库，大概就这么一回事，至于为什么从库会分IO线和SQL线程，我这里就不详细解说了，我们知道原理后，本次的事件就容易下手分析了。

在MYSQL里我们使用show slave statusG 来查主从当前的读取情况 ，从IO传输进程看Slave_IO_Running: Yes,从SQL应用进程看Slave_SQL_Running: No， 而且错误也很明显Could not execute Write_rows event on table skdata_2021.pj_zzspdz_fpmx; Duplicate entry 043002000111-01278925 for key ak_key_2, Error_code: 1062; handler error HA_ERR_FOUND_DUPP_KEY; the events master log master-bin.000403, end_log_pos 333202176。

那我们尝试第一个方法，就是在从库看看这个数据是否存在,我们根据唯一的KEY，在从库不断删除这个旧记录，删除记录之前一定要备份，分三个步骤：备份记录，删除重复记录，启动进程，不过可惜，这种方式又引来了第二个报错UPDATE报错：

Could not execute Update_rows event on table skdata_2021.qrtz_scheduler_state; Cant find record in qrtz_scheduler_state,

Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND; the events master log master-bin.000403, end_log_pos 333327330

那此时是发现记录不存在，我们尝试用mysqlbinlog工具把对应的前记录数据行查询出来

使用mysqlbinlog主库操作：

mysqlbinlog --no-defaults --base64-output=decode-rows --verbose  --start-position=333326998 --stop-position=333327330 master-bin.000403

把更新前记录找出，并在从库插入执行，再启动slave sql进程。

至此，该错误解决，但又出现数据冗余错误，没办法了，要放大招才行，记得在新特性有这样的一个参数：slave_exec_mode，通过下面的操作：

从库操作：

show variables like %slave_exec_mode%;

set global slave_exec_mode=IDEMPOTENT;

stop slave;

start slave;

确认主从无延迟及确认数据一致 操作完后，修改回去

最后，通过几次尝试和分析，放大招后，数据恢复正常，  再后面通过查询从库当前状态，

开始会有延时，毕竟停了一段段时间，经过半个小时，追数据后，同步恢复正常，从库报表查询也相应恢复，各业务也恢复正常，本次事件到此告一段落。

就本次问题，我得出一个个人的看法，在我们日常运维过程中, 出现问题时，要先从数据库本身原理进行分析，再根据错误进行尝试，但是必须要做相应的备份，备份重于一切，同时要不断的学习数据库的新特性，不断提高自己这方面的能力， 在处理完后，要进行故障复盘，进行故障总结，写好相应的故障处理步骤，像这种问题已经出现过多次，都能通过这个方法解决。

END

更多精彩干货分享

点击下方名片关注

IT那活儿