数据库备份的动态调度设计和思路

这是学习笔记的第 1786篇文章

关于数据库备份任务的优化，整体可做的改进就是以下几个方面：

1. 备份任务不应该同时触发，如果有100个备份，都是在同一时间触发，那应该是一种很糟糕的情况
2. 备份任务的执行时间应该可控，比如有100个任务，那么这些任务总体的起始时间和结束时间应该可控，如果截止时间不可控，那么也是一种混乱状态

在此之上，就是一些细节的改善了。之前介绍过一篇MySQL备份任务的文章

通用crontab接入任务调度的思考

总体来说，如果切入点是备份，其实直接接入celery不是一个很理想的方案，因为备份任务的执行时间一般都偏长，而且任务的执行结果很重要，如果没备份或者备份任务重复执行，对于线上业务的影响还是很大的，所以对于celery的切入点建议有两个：

1. 最好执行粒度是一些小任务，比如执行个简单的脚本或者检查。
2. 执行的频率和数量要多，通过大量的实践来验证会得到更多的思路。

在这个基础之上，接入备份任务是一个相对自然的事情。 做到的一个折中就是通过crontab来触发任务，而celery只是支持了异步修改crontab的时间配置。所以目前来看，需要做到的深度定制就是任务的编排和时间的编排。

目前基本就是静态的处理，通过自定义的算法是可以支持的。换句话说，我要调度哪些任务都是提前做好配置，然后启用调度器来完成调度分布。这些配置是静态的，一成不变的。所以我们如果需要做得更好，更可控，我们需要引入动态调度。

动态调度的意义是什么，主要就是因为变化，可能的变化有：

1. 备份集个数的变化，如果发生变化，需要手工标识
2. 数据库的数据量很可能随着时间的变化而变化，这个通过历史的数据可能不够准确
3. 备份的结果集大小可能随着数据量的变化而变化
4. 备份的时间区间也会随着手工调度触发而产生变化，比如之前是1:30触发，结果重新调度之后是2:30
5. 如果有的任务是全新的，那么它缺少一些必备的维度数据，比如历史备份数据量，备份时间等

这些因素中，我们需要做一些改进，需要通过动态调度来满足几个大体的需求或者改进，而且这个改进目标要足够清晰。 我这边考虑了两个：

1. 备份任务的编排，到底开启几个并行进程最佳
2. 备份任务的区间，可以改进到什么程度，比如之前是1：00-3:00，如果通过编排的方式，优化到1:30-2:30，那么这就是一种可见的改进。

所以动态调度不光是启用调度器，而是需要通过大量的计算来得到一个相对高效的执行计划，然后通过历史的执行记录来不断的校正，最终让任务的执行高效可控，而且支撑一键式变化。

这里需要建立一类模型，首先是对于调度器中所做的算法实现，目前是基于备份时间来设计的，其实完全可以切换为另外一种单位形式，比如数据量，比如备份集大小等。

第二类是对于调度基准的改进，如果新服务器没有历史备份数据，我们可以根据预先设计的模型给予参考，比如备份1G需要1分钟，这种粒度的数据配置是根据实践和经验共同组合完成的。有了基准模型，才能知道历史的备份有没有问题，有没有明显的调度问题。 同时，后续要接入备份配置的时候，也就有了相对准确的参考数据。

第三类是对于历史数据的分析，也是此次调度中的核心部分，那就是通过历史数据的分析和计算，能够得出初步的结论，比如开启几个并行最为合适，备份的时间窗口等。

第四类是对于这个任务的调度，应该是自动触发，需要通过事件或者阈值的方式来触发。尽可能保证不要无理由的频繁变更，而是变更都在计划内，改动幅度较小。