故障分析 | MySQL 数据”丢失”事件之 binlog 解析应用一则

备注:考虑信息敏感性,以下分析场景测试环境模拟,相关数据做以下说明

发现了一些端倪,在mysql-bin.000004中有对该表的2次truncate *** 作,等等,好像发现了什么,那条丢失的数据也是在这个mysql-bin.000004文件中,梳理下逻辑,难道那条记录在2次truncate之间,于是单独对这个binlog做详细解析,得到以下信息

到此基本了解了这条记录为何会诡异丢失了 ,与客户确认跑批灌数据的逻辑,了解到会对该表做truncate,但由于 误 *** 作 ,在跑批开始后,又触发了一轮truncate行为,导致已经插入到该表的部分数据再次被清理了,也就导致了在解析binlog时部分记录丢失了,但并未观测到有删除的行为,而是被truncate方式清理.

备注 :虽然binlog记录的信息足够多,但当故障原因定位后,由于其并未记录 对该 *** 作的IP及用户 信息,如果不开审计,也只能知道发生了该行为,但无法具体定位触发该行为的"人".

mysql要实现定时执行sql语句就要用到Event

具体 *** 作如下：

先看看看event 事件是否开启

show variables like '%sche%'

如没开启，则开启。需要数据库超级权限

set global event_scheduler =1

创建存储过程 update_a (注：就是你要执行的sql语句)

mysql>create procedure update_a() update a set a.y_avg=(select avg(b.youhao) from b where a.a_id=b.a_id)

创建一个定时任务：event e_updateA

mysql>create event if not exists e_updateA

->on schedule every 60 second ---设置60秒执行一次

->on schedule at date_add(now(),interval 1 minute) ---在一分钟后执行

->on completion preserve

->do call update_a()---执行update_a()存储过程

创建Event之后，sql语句就定时执行一次。

关闭事件任务

---