MySQL随机恢复的几个段位
source link: https://mp.weixin.qq.com/s?__biz=MjM5ODEzNDA4OA%3D%3D&%3Bmid=2650318243&%3Bidx=1&%3Bsn=fc5f9d946fe52f8fc4c469679eacdc31
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
这是学习笔记的第 2312 篇文章
对于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个层级会把恢复转化为一个通用问题，对于如何衡量恢复能力在没法实现全量数据集恢复的前提下，可以基于统计学的模型进行假设检验，最终的目的是通过一个有效样本数据进行统计量的评估和分析，这个部分的内容理论深度其实没那么复杂，是一种全新的思维逻辑去评估恢复质量。
各大平台都可以找到我
-
微信公众号：杨建荣的学习笔记
-
Github：@jeanron100
-
CSDN：@jeanron100
-
知乎：@jeanron100
-
头条号：@ 杨建荣的学习笔记
-
网易号：@杨建荣的数据库笔记
-
大鱼号：@杨建荣的数据库笔记
-
腾讯云+社区：@杨建荣的学习笔记
近期热文：
转载热文：
QQ群号： 763628645
QQ群二维码如下， 添加请注明：姓名+地区+职位，否则不予通过
点 在看 ，让更多人看到
Recommend
-
61
走过“钻石”段位，来到“王者”前夜，直播还能玩出什么花样？
-
16
策略产品经理二三事（3）假如策略PM有段位产品经理话题下的优秀回答者产品经理的能力和职级对应关系其实一直都有，不过貌似这么长时间也没什么变化。这些能力级别基本是围绕业务结...
-
12
文案的四个段位 作者： 左尔击...
-
12
本文转载自微信公众号「杨建荣的学习笔记」，可以通过以下二维码关注。转载本文请联系杨建荣的学习笔记公众号。
-
8
一道关于Axure的面试题：瞬间测出你的产品段位...
-
4
本文基于 https://pomb.us/build-your-own-react/ 实现简单版 React。本文学习思路来自
-
10
【2021】🙌1024程序员段位/Level大挑战，最高赢1024现金大奖！堆堆3天前
-
13
1️⃣0️⃣2️⃣4️⃣！祝一G棒的程序工程师们，节日快乐呀🤟~值此佳节之际，HeapDump性能社区必有大动作；这不，堆堆马上就来派福利了！High大了，High大了，这才是给各位工程师大大们过节的🔝正确姿势！1024 Part1👆长按扫码或手机...
-
5
大家好，我是林三心。前几天跟leader在聊深拷贝leader：你知道怎么复制一个对象吗？我：知道啊！不就深拷贝吗？leader：那你是怎么深拷贝的？我：我直接一手JSON.parse(J...
-
10
情人节酒店的段位之争，00后、90后、80后偏好新鲜出炉！ 0评论 2022-02-14 13:20:00 来源：中国网科技 ...
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK