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