这是学习笔记的第 2063 篇文章
今天做了一次数据异常恢复，算是有不少的心得和感受，总结一下。
最近碰到的数据问题还是不少，这个过程中也发现了一些隐患，每次恢复的策略和方法都不大一样，但是最终还是修复了数据。
这是一套简单的主从环境，因为环境刚上，备份配置没有统一检查。
快到中午的时候，同事问我能不能做下数据恢复，因为在11:00左右发生了应用的逻辑问题，导致误删了一些数据，所以快到的中午的时间，他是希望把这些数据修复一下。
实际了解的情况，发现远比我想象的要复杂，这些操作涉及3张表，有些表是做了误删除，有些表是做了多余数据的写入，结果开发同学尝试修复，结果发现越修越乱，现在如果要恢复这半个多小时的数据还是有点难度的。
不管怎么样，我们先来看看备份，先取一下昨天的备份吧，我连接到主库，发现配置的定时备份任务被禁用了，我看到这里还暗自夸我的同事想，这个配置是标准规范的，备份任务应该配置到从库，结果连接到从库发现，备份任务同样被注释了，这个时候让我有些意外，紧接着我使用命令show binary logs查看binlog的情况，发现001号binlog还存在，那这个问题就好办了。
我带着一些方案和开发同事沟通，首先这个操作的时间比较近，走全量备份恢复的效率不是很高，可以尝试做DML闪回，即得到11:00左右的变更语句，然后得到闪回语句。整个过程涉及的数据变更不多，算是可逆的操作。
和同事信心满满的使用binlog2sql来恢复，结果收到了工具的报错，看起来是解析的过程中碰到了特殊字符的处理出现了问题，尝试缩小日期范围还是得到同样的报错，所以至此我们需要调整恢复的方向。
现在我们拥有全量的备份，总的binlog量在600M左右，我们可以反向来恢复，即恢复数据库从初始化开始到出现逻辑错误的时间点，这样就能够基本保证整体数据的完整性了，而这个时候为了稳妥起见，已经让这个业务逻辑停止了数据操作。
恢复的过程还是比较顺利的，恢复时间要比实际预期的长一些，而这个也是我们需要不断细致优化的。
对于这次恢复，我有以下的一些总结：
- 梳理备份的情况，查漏补缺
- 通过数据恢复，恢复成功了可以加深和业务的互相理解，后续要开展权限管理工作会方便的多。
- 对于恢复工具的不断打磨，提前恢复工具的性能和稳定性
- 对于binlog的管理需要做统筹管理，而binlog的部分可以细化做成一个订阅服务。
- 对于恢复方案的进度，需要和业务方不断反馈，这样可以始终保持一种互助的氛围。
- 数据恢复时，如果要覆盖已有的数据，一定要做备份，保证操作可逆
- 提高数据恢复的效率和可控性，比如恢复数据可以较为准确的根据方案估算出恢复的预计时间。
