对于MySQL数据恢复而言，其实很多时候都会有点儿不踏实，大多数情况下备份恢复体系的建设是一气呵成的，建设完善之后保持原样，就很少干预和测试了，而一旦需要恢复的时候，才发现这也不好，那也不完善，轻则花费重金恢复，重则是职业生涯的终点。
所以我们在数据恢复的时候，我们特意完善了一个功能，那就是随机恢复，随机恢复主要实现两个功能：基于备份集恢复和基于时间点恢复。基于备份集恢复相对比较简单，就是什么时候做的备份，一定要恢复出来，而基于时间点会复杂一些，比如数据库可以恢复到10:00:00，是需要实现精确到秒级的恢复能力，我们在此更进一步，生成一个随机时间，然后让服务按照指定的时间点进行恢复，每天大约会跑10个左右的任务，都是随机从服务组中抽取。
经过一段时间的调整和验收，从50%左右的成功率不断调整，到了现在的93%左右的成功率，我的初步要求是两个9，这个标准提了一段时间了，从实践的结果来看，这个标准要达成付出的代价和心血是很多的，远远不是看上去的那么轻松。
对此我对随机恢复设置了3个段位，可以作为参考。
第一层级：随机抽样+单机恢复
这一层级思路很简单，随机从服务组中选取一个实例，到指定的恢复机恢复，只要数据库能够正常启动则标识成功，否则，如果因为参数兼容性，版本差异，空间瓶颈，插件问题等导致无法启动，都会标记为失败。
当然这种模式的缺点也很明显，那就是随机的模式，最尴尬的无非是同样的实例被反复选中，或者全是大块头的实例，对恢复造成很大的压力导致失败，另外则是恢复机成为瓶颈，跨机房流量和空间限制，会导致单一的恢复机难以支撑更高的指标要求，这也是早期难以突破1个9的主要原因。
第二层级：随机抽样+多IDC节点负载均衡
这种思路可操作性很强，优点会很明显，原本的恢复任务可以随机的分配在不同的IDC中，对于跨机房流量消耗是一种很大的改良，同时也可以大大提高随机恢复的吞吐量，比如我们原本可以跑10个随机恢复任务，那么如果我们加到15个任务也可以说是轻轻松松。
第三层级：随机策略调度+多IDC负载均衡
这是我认为目前改进空间很大，能够迭代进入2个9的关键阶段。可以从如下的方面考虑：
1)恢复服务器实现多版本插件式部署，对于恢复服务器而言，不需要默认数据库版本，所有差异化版本都是插件式目录，可以快速构建恢复服务器，提高恢复扩展能力
2)根据恢复服务器的存储和配置进行定制化延迟启动，比如有的服务器CPU配置好一些，启动数据库快一些，有些数据库启动要略慢一些，可以通过配置化实现延迟启动的问题，避免数据库启动中的一些尴尬问题
3)大容量实例在指定服务器中调度恢复，节省资源成本，比如有一个实例容量是800G,那么恢复机需要在900G左右，那么不是所有恢复服务器都需要900G,通常来说，这是极个别的现象，比如通用配置500G就足够。
4)大容量的实例尽量减少调度频率，如果一个实例的容量较大，恢复成本较高，那么我们可以有效恢复的基础上调整恢复优先级
5)未恢复的实例需要优先调度，如果有1000个实例，如果经过了很长时间，恢复的覆盖范围始终覆盖不了大多数实例，其实随机恢复的设计是有问题的。需要照顾到那些没有被调度到的实例
6)实现弹性调度，比如对于容量小的实例，恢复效率会快很多，那么我们势必就可以增加这类实例的恢复数量，而如果选中的实例容量较大，则可以在时长，数量方面做一些调控。
第4层级：根据统计学模型假设检验
在第3层级的基础上，达到了两个9的前提下，第4个层级会把恢复转化为一个通用问题，对于如何衡量恢复能力在没法实现全量数据集恢复的前提下，可以基于统计学的模型进行假设检验，最终的目的是通过一个有效样本数据进行统计量的评估和分析，这个部分的内容理论深度其实没那么复杂，是一种全新的思维逻辑去评估恢复质量。
本文转载自微信公众号「 杨建荣的学习笔记」，可以通过以下二维码关注。转载本文请联系 杨建荣的学习笔记公众号。
