关于数据恢复:故障分析-生产系统数据丢失后的恢复

作者：华融科技 刘宝珍
本文起源：转载自公众号 -MySQL 解决方案工程师
* 爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。

一、背景和大略的思路

2020 年 2 月 25 日，微信的朋友圈大量转载微盟遭逢了零碎重大故障（36 小时内尚未复原外围生产数据）。从而想到自己在两周前解决的一个案例：开发人员误删除了生产数据，自己复原的一个过程。同时给这个故障的处理过程做一个总结，也对学过的常识做一个梳理，心愿对运维的同学们有一个警示作用。

2 月 13 日 23:00 接到微信告诉，是否帮忙复原数据。

零碎环境信息如下：

• 操作系统：RHEL7.5
• 数据库：MySQL 5.7 社区版，一主两备

23:05 开始染指数据失落的故障。确认一个大略解决问题的思路：

1. 找到是什么人在什么工夫点做了什么操作？
2. 这个操作对系统的影响有多大，是否对其余零碎有影响？确认这个操作是不是失常业务体现？
3. 确认数据库里受到影响的日志的时间段
4. 在仿真环境复盘整个故障
5. 制订技术复原计划，在仿真环境验证数据恢复计划
6. 在仿真环境验证数据恢复后利用是否失常
7. 备份生产环境数据，利用数据恢复计划到生产环境
8. 生产环境绿灯测试，无误后，复原实现

因为复原生产数据是重大的数据调整，须要报请领导批准，须要有齐备的数据回退计划。

二、数据恢复过程以及技术剖析

用了 5 分钟理清了解决这个问题思路，接下来就是思考具体的数据恢复了。在解决这个问题过程中，有两个难点须要解决。

1. 确认要复原的 binlog 的开始和完结。
2. 依据 binlog 的开始和完结，确认数据恢复计划，以及是否须要须要排除在这个时间段产生的其余烦扰数据。

首先解决第一个问题。

1. 询问开发人员，开发人员给出晚间大略 20:20 左右操作 rest 接口，调用了 activity（以下简称工作流）平台删除流程模板的操作，导致该流程模板下所有的流程实例全副被删除，在该流程模板下有 5 个在途的流程尚未解决实现。
2. 依据开发人员的形容，登录到工作流平台的数据库，查看数据库在 20:20 左右的 binlog 文件，并对 11 号 binlog 文件进行备份。
3. 将 binlog 拷贝到一个开发的服务器，通过 mysqlbinlog 进行解析。解析命令为：

mysqlbinlog -v --base64-output=decode-rows \
--skip-gtids=true --start-datetime='2020-02-13 20:10:00' \
--stop-datetime='2020-02-13 21:30:00' \
-d {$DBNAME} mysql-bin.000011 >>aa.log dbname

1. 察看解析后的 SQL，在 20:20 分并未发现大量的删除操作，确认开发人员的话不可信，做故障诊断的第一准则：任何人的话都不能全信，也不可能不信，带着疑难来找到论据证实他的说法。
2. 持续翻看解析的 binlog，20:30 开始呈现大量的 DELETE 和 UPDATE 等操作，开始狐疑这一点是不是有问题的时间段。
3. 将这一段的 SQL 进行演绎总结，演绎须要操作几个表，对这个几个表的操作类型，以及操作的数据的类别（业务 ID）。同工作流平台的共事进行确认，删除一个工作流的模板，是不是波及到这些表的变更，工作流平台的共事确认是这个过程，数据恢复的心愿诞生了！
4. 依据以前的教训积攒，Github 上有个开源我的项目 binlog2sql，能够将 binlog 的 event 翻译成 SQL 语句，也能够翻译成反向 SQL，登时感觉这个问题应该很“容易”解决了。
5. 依据以上思考，开始在仿真环境里装置 binlog2sql 工具，该工具就是一个 Python 的程序，须要装置好 Python 环境以及须要的三方库即可，具体的应用形式请参考：https://github.com/danfengcao…，同时也再次感激工具的作者曹老师。
6. 在仿真环境里，复原生产环境有问题的实例，同时在工作流平台将利用的 JDBC 的 URL 指向新的复原好的实例。

以上几个过程，曾经解决了第一个问题，接下来咱们要解决第二个问题。

1. 在以上的步骤里，曾经在仿真环境复盘了生产环境的故障，同时在也仿真环境里里装置了 binlog 转成 SQL 的工具。
2. 应用 binlog2sql 的工具，解析进去谬误执行的 SQL，让工作流的平台的同时进行确认，同时让工作流的共事，确认在这个时间段内没有其余的利用也在操作这个数据库。
3. 工作流的共事确认 SQL 全副为误操作产生的 SQL。

具体的确认形式如下：

1）在仿真环境模拟创立一个工作流模板。

2）在这个模板上创立几个测试实例

3）通过接口去删除这个工作流模板，察看利用产生的 SQL，以此来确认自己提供的 SQL 是否正确。

同时，工作流平台确认在问题时间段内无其余利用操作，感觉胜利在望了，该问题能够轻松解决了。

4）通过 binlog2sql 生产反向 SQL，把 SQL 利用于仿真环境，问题就能解决了，仔细观察反向 SQL 文件，发现外面有一些乱码，查看乱码字段所在的表，发现表的定义是这样的。

表中有个字段为 longblob 字段，产生的 INSERT 的 SQL 无奈执行，这个问题该怎么解决？？

5）这个问题到这里陷入了僵局，眼看马上就能解决的问题，发现有一个表数据无奈通过 SQL 进行插入，询问工作流平台共事，这个表是否很重要，失去回答，没有这个表的数据，零碎无奈运行。

6）换个思路考虑一下，既然 SQL 是通过二进制的 binlog 生成的，能够思考生成反向的二进制 binlog，而后把这一段反向的 binlog 利用到数据库，这个问题就解决了。

7）带着这个思路，去 Github 里翻看了我的项目。果然还真有一个：https://github.com/Meituan-Di…

再次非常感谢美团点评开源的 myflash 我的项目。

8）利用 myflash 生成了反向二进制文件，把文件利用到数据库，工作流平台在仿真环境测试，数据完满再现。

三、问题的反思

通过以上剖析，基本上就能够轻松解决这个问题。对本人提出几个问题：

问题 1：为什么不必备份复原的形式进行数据库复原？

在这个零碎上，数据曾经备份了，每天都有全备，不能应用这个复原的起因，工作流平台里有很多利用的流程引擎，一旦做了基于工夫点复原，别的利用的零碎数据一块被复原了，将会导致别的零碎会失落一部分数据。

问题 2：为什么不基于表的数据恢复？

因为工作流平台是一个开源的平台，数据模型之间的关联性特地强，如果基于表的复原，容易导致数据的束缚呈现问题。

反思 1：为什么在生产环境呈现失落数据的状况？

开发人员在生产上线过程越过了仿真环境，间接上生产，对生产上线过程并不谨严，尽管有治理流程，然而对流程的过程执行不力。

反思 2：研发人员的技术能力

研发人员对 activity 并不相熟，对于批改流程模板的流程也不相熟，进步研发人员的技术能力必须要提上日程。

四、后续问题

联合以上剖析过程，须要指定一些辅助策略来欠缺公布流程。

1. 公布流程自动化，利用代码公布自动化公布，尽量避免人为参加。
2. 利用公布流程标准化，所有的脚本和上线的新的利用的步骤必须通过验证能力上线。