oh no！mysql数据丢失了

最新推荐文章于 2024-06-15 16:09:53 发布

柯柏技术笔记

最新推荐文章于 2024-06-15 16:09:53 发布

阅读量1.2k

点赞数 25

文章标签： mysql adb 数据库

本文链接：https://blog.csdn.net/qq_33228984/article/details/135392897

版权

背景

业务开发反馈，使用的的mysql数据库，某表数据部分丢了，需要还原这张表最近的备份数据排查、修复。

数据丢失，严重了!!!

排查解决历程

第一次排查

还原数据

线上数据，我们的策略通过mysqldump每小时备份一次，根据业务提供的时间节点，找到相邻的最近时间的备份数据，还原到测试环境，提供给业务开发，跟线上数据比对，找出的丢失的数据进行还原。

业务开发反馈，还原的数据没有丢失的数据，接着继续还原了几个备份数据，结果还是说没有，但业务咬死数据就是丢失了。

我只能怀疑，代码是里面是不是有delete语句删除的，或者本地通过数据库工具直连线上数据库，这种做法，是非常不安全的，非常不推荐，线上数据库的权限就应该牢牢的掌握在dba的手里。

review代码

下载业务代码，查找丢失的数据的表，是否存在delete语句，结果找了一圈，没有，唉。那只能怀疑是不是人为通过数据库工具连上线上数据库删除的，只能看下binlog日志了

查看binglog日志

binlog用于记录数据库执行的写入性操作（不包括查询）信息，以二进制的形式保存在磁盘中。binlog是MySQL的逻辑日志，并且由Server层进行记录，使用任何存储引擎的MySQL数据库都会记录binlog日志。

逻辑日志：可以简单理解为记录的就是SQL语句。
物理日志：因为MySQL数据最终是保存在数据页中的，物理日志记录的就是数据页变更

懵逼了，日志里面也没发现数据丢失表，对应的delete语句。排查就这样结束了…

结论

数据丢失了，原因也没找到，一口大锅飞过来了，业务开发给出的事故报告，运维组维护的mysql中间不稳定导致数据丢失，原因未找到。这个锅也只能背了，学艺不精，怪谁呢？

锅背了，该有的策略还得加上，杜绝下次出现这种事故的发生。终极大招-审计日志

审计日志

数据库审计功能主要将用户对数据库的各类操作行为记录审计日志，以便日后进行跟踪、查询、分析，以实现对用户操作的监控和审计。审计是一项非常重要的工作，也是企业数据安全体系的重要组成部分，等保评测中也要求有审计日志。对于 DBA 而言，数据库审计也极其重要，特别是发生人为事故后，审计日志便于我们进行责任追溯，问题查找。

审计日志攻略，这篇文章无意间看到，写的挺好，可以看下mysql的审计日志是怎么玩的。有区别的地方，我使用的审计插件是Percona Audit Log Plugin

呵呵，审计日志开启，我就看看数据到底是怎么丢失的。

第二次排查

没过多久，业务反馈数据又丢了，查看审计日志，找出对丢失数据表的操作，结果没找到delete 、truncate删除表的数据的语句，说明数据不存在删除，也不存在丢失一说。

我弱弱问了一句，你们判断数据丢失的依据是什么？重点来了，自增id不连续，中间缺少了一部分数据

这玩笑开大了，这种结论都能下，浪费我这么多精力

mysql自增策略，只保证递增，没说连续，再说了业务数据依赖自增，也是非常不合理的。

我怀疑是数据没插入进去，回滚导致的吧，查看binlog日志，完全印证我的猜想，看图：

业务的反馈：

跟binlog记录的数据完全吻合，查找应用的日志，也发现了，对应这张表的数据插入有回滚异常的日志记录。

mysql自增主键为什么不是连续的，这是今天的知识点，跟着我一起分析下

mysql自增主键为什么不是连续的

不连续的三种场景

先讲下导致不联系的三种场景，大家可以自己试试

唯一键冲突导致自增主键不连续
事务回滚导致自增主键不连续
批量插入数据导致自增主键不连续

上面都场景，就是回滚导致的不连续

自增值保存在哪

在 MySQL 5.7 及之前的版本，自增值保存在内存里，并没有持久化。每次重启后，第一次打开表的时候，都会去找自增值的最大值 max(id)，然后将 max(id)+1 作为这个表当前的自增值。
举例来说，如果一个表当前数据行里最大的 id 是 10，AUTO_INCREMENT=11。这时候，我们删除 id=10 的行，AUTO_INCREMENT 还是 11。但如果马上重启实例，重启后这个表的 AUTO_INCREMENT 就会变成 10。也就是说，MySQL 重启可能会修改一个表的 AUTO_INCREMENT 的值。
在 MySQL 8.0 版本，将自增值的变更记录在了 redo log 中，重启的时候依靠 redo log 恢复重启之前的值。