蓝盟IT小贴士来喽！
最近，进一步优化随机恢复的成功率问题，本来预计在两周内迅速结束，从一个9的恢复能力迅速提高到两个9，结果这个Flag立了起来，但最终的结果和努力比预想的要高。
事实上，很多同学不理解为什么两个9那么难。 总体而言，数据备份基于一次总量永远增长的模型，由于数据量增长，数据动态变化，以及如何恢复数据的需求是动态的，例如这次是232:00，下次是336000 此外，大多数问题都发生在数据库启动过程中，通常与存储容量、插件配置和参数配置有关。 如果发生错误，手动修正也可以解决。 如果有启动错误，会根据失败进行计算，所以检查标准比较简单明确。
最近的沉淀表明，成功率从93%下降到88%。
基于以往的失败数据，我的第一次测试选了23个样本。 恢复过程比较快，恢复到dn1这个恢复机器后，指定恢复成功率达到100%，有点吃惊。
然后选择了dn2，再次恢复了同样的23个样本实例，这次失败了3个，但是再次恢复就没有问题了。 真的很意外。
通过这样的测试，我进一步进行了分析，发现问题主要出现在binlog的播放面上，所以可以初步判断binlog的有效性方面还有潜在的问题，目前的随机时间范围在3-24小时以内，所以我先
关于任务调度时间，我进一步分析，发现还是有潜在风险的，现在的测试基数还比较小，每三个小时执行一次，按照两个定时任务触发的模式，一天差不多有12个左右的任务
这种调度模式的缺点是执行任务不灵活，如果数据恢复时间超过一个小时，基本上就会失败。 另外，dn1、dn2、dn3的任务选择也是随机的，如果选择dn1进行恢复，则下次dn1的恢复也很有可能随机继续，dn2、dn3都有可能变为空闲状态。
一个理想的方法是可以定制恢复基数。 例如，现在是12次，基本上每小时都会触发。 如果需要20次恢复，则每台恢复机的呼叫次数几乎为7次，相对较缓慢。 在强调度模式下，可支持的基数最多为48次左右。而且，如果在dn1恢复后立即建立触发下一波恢复任务的即时响应模式，该基数的提高将直接增加3倍，仍然很强。
所以马上要做的改进是充分利用这三台恢复机器，不让他们经常处于空闲状态。 否则就是下一个状态。
文/上海蓝盟 IT外包专家
中文
电话咨询
微信咨询
公众号
