近期，我们正在进一步优化随机恢复的成功率。原本预计2周内快速完成，从1个9到2个9的恢复能力迅速提升。结果这个Flag就立好了，但是最后的结果和付出的努力远比想象的要高。其实很多同学不太明白为什么两个9这么难。一般来说，数据备份是基于一次性、全量、永远增量的模型，数据量会不断增长，所以数据是动态变化的。另外，如何恢复数据的需求是动态的。例如，我可以随机指定一个时间。比如这次是2:00，下一次可能是3:20。不确定的时间会给现有服务带来新的潜在不确定性。问题大多发生在数据库启动过程中，通常与存储容量、插件配置、参数配置等相关。如果报错，虽然也可以人工修复，但是只要启动报错，我们也会算作故障，所以验收标准是比较简单明了的。最近经过一段时间的沉淀，发现成功率从93%下降到88%。为了保证恢复任务的执行，目前使用crontab模式，如下：307-23/3***/usr/bin/python/root/crontab_tasks/random_recover.py>>/root/crontab_tasks/log/random_recover.log&006-22/3***/usr/bin/python/root/crontab_tasks/random_recover.py>>/root/crontab_tasks/log/random_recover.log&为了提高恢复的吞吐量和效率，三个恢复机目前都是基于IDC实现动态调度。根据之前的故障数据，我在第一轮测试中选择了23个样本，恢复过程比较快。指定恢复机dn1后，恢复成功率达到100%，让我有点意外。然后我重新选择了dn2，并再次恢复了相同的23个示例实例。这次3失败了，再次恢复就没有问题了。能通过这样的考试，着实让我吃惊。我进一步分析发现问题主要出现在binlog的回放上，所以可以初步断定binlog的有效性还是存在潜在的问题。目前的随机时间范围在3-24小时内，所以特意先调了一下。时间框架，先缩短它。至于任务调度时间，我进一步分析发现，还是有潜在风险导致的。目前的试验基地还比较小。按照3小时执行一次，2个定时任务触发的模式，一天大概有12个。任务。这种调度方式的缺点是任务的执行没有灵活性。如果数据恢复时间超过一小时，基本就失败了。另外，dn1、dn2、dn3的任务选择也是随机的。隐患是如果选择了dn1恢复，下次很可能会继续随机恢复dn1，导致dn2和dn3一直处于空闲状态。更理想的方式是自定义恢复的基数。比如目前是12次，基本上每小时触发一次。如果我们需要恢复20次，那么平均出来每台恢复机的调用次数差不多是7次，比较松散。如果采用强调模式，最大可支持的次数约为48次。如果更进一步，做成即时响应模式，即在dn1恢复后立即触发下一波恢复任务，那么这个基数的增幅将直接乘以3，相当厉害。所以马上要做的改进就是利用这3台回收机，让它们不至于一直闲置。否则就是下面的状态。本文转载自微信公众号《杨建荣的学习笔记》，可通过以下二维码关注。转载本文请联系杨建荣学习笔记公众号。
