MySQL备份调度自动化实现思路
这是学习笔记的第 1775篇文章
昨天整理了下备份调度的思路 批量任务的并发调度和时间调度，整体来说已经自己已经思路很清晰了，所以今天就开始实现整个过程。
为了表决心，今天让同事给我匀了一批MySQL实例出来，在晚上做好充分测试之后直接发布到线上开始做时间调度的自动化配置，整体来说，达到了预期的效果。
整个过程涉及几个页面，我简单提取出来一个。
做调度的部分，分为两个部分，一个是任务调度，也就是任务的并行调度，另外一个是时间调度，比如我们可以设定一个起始时间，按照时间调度后的情况可对后续的任务设置相应的执行时间，整个过程可以都放在crontab里完成，也可以推送到celery完成。
要触发调度需要输入两个参数，一个是起始时间，另外一个是并行度。
调度后的基本效果如下：
这个过程涉及到两个算法，一个任务并行的调度算法，另外一个就是时间调度的算法，时间调度是在任务并行调度的基础上完成的。
时间调度的基本代码如下，思路是根据已有的分组和起始时间，来预估后续的任务的起始时间。
for j in range(len(array_group[i])):
print ('test:', i, j, array_group[i][j])
duration_seconds = mysql_xtrabackup_scheduler.objects.filter(id=array_group[i][j])[0].duration_seconds
diff_seconds = 60
if j == 0:
end_time = new_time + datetime.timedelta(seconds=int(duration_seconds) + diff_seconds)
print "new_time:", new_time, "end_time:", end_time, new_time.hour, new_time.minute, duration_seconds
else:
new_time = end_time
end_time = end_time + datetime.timedelta(seconds=int(duration_seconds) + diff_seconds)
print "new_time:", new_time, "end_time:", end_time, new_time.hour, new_time.minute, duration_seconds打个比方，部分调度生成的日志如下，可以看到一个有序的数据可以在依次计算后续的执行时间。('array_group', [[11100L, 3300L], [10400L, 3300L], [9600L, 3700L, 100L, 100L], [6600L, 5900L, 3000L]])
0 [11100L, 3300L]
1 [10400L, 3300L]
2 [9600L, 3700L, 100L, 100L]
3 [6600L, 5900L, 3000L]
0 [3L, 73L]
[3L, 73L]
('test:', 0, 0, 3L)
new_time: 2017-08-28 01:00:00 end_time: 2017-08-28 04:06:00 1 0 11100
('test:', 0, 1, 73L)
new_time: 2017-08-28 04:06:00 end_time: 2017-08-28 05:02:00 4 6 3300
1 [55L, 47L]
[55L, 47L]
('test:', 1, 0, 55L)
new_time: 2017-08-28 01:00:00 end_time: 2017-08-28 03:54:20 1 0 10400
('test:', 1, 1, 47L)
new_time: 2017-08-28 03:54:20 end_time: 2017-08-28 04:50:20 3 54 3300
2 [32L, 38L, 202L, 203L]
[32L, 38L, 202L, 203L]
('test:', 2, 0, 32L)
new_time: 2017-08-28 01:00:00 end_time: 2017-08-28 03:41:00 1 0 9600
('test:', 2, 1, 38L)
new_time: 2017-08-28 03:41:00 end_time: 2017-08-28 04:43:40 3 41 3700
('test:', 2, 2, 202L)
new_time: 2017-08-28 04:43:40 end_time: 2017-08-28 04:46:20 4 43 100
('test:', 2, 3, 203L)
new_time: 2017-08-28 04:46:20 end_time: 2017-08-28 04:49:00 4 46 100
3 [65L, 71L, 11L]
[65L, 71L, 11L]
('test:', 3, 0, 65L)
new_time: 2017-08-28 01:00:00 end_time: 2017-08-28 02:51:00 1 0 6600
('test:', 3, 1, 71L)
new_time: 2017-08-28 02:51:00 end_time: 2017-08-28 04:30:20 2 51 5900
('test:', 3, 2, 11L)
new_time: 2017-08-28 04:30:20 end_time: 2017-08-28 05:21:20 4 30 3000这是一个放大的效果图，比如第1组的任务计划是1:00开始，执行时间是1110秒，则后续的任务时间范围会额外加1分钟，会从1:19开始；第2组的任务也是从1:00开始，执行了1040秒，额外加1分钟，则从1:18开始；第3组的任务也是从1:00开始，根据执行时间，有1:17,1:24,1:25 三个后续的子任务。
整体这样计算下来，crontab的任务执行时间就完全可以根据策略来定制了，定制之后，我们通过批量处理的方式推送到系统crontab中，整个过程就会完成任务的分发和修改，可以真正实现一键配置。
本文参与 腾讯云自媒体分享计划，分享自微信公众号。
原始发表：2018-10-16，如有侵权请联系 cloudcommunity@tencent.com 删除
评论
登录后参与评论
推荐阅读
相关产品与服务
云数据库 MySQL
腾讯云数据库 MySQL（TencentDB for MySQL）为用户提供安全可靠，性能卓越、易于维护的企业级云数据库服务。其具备6大企业级特性，包括企业级定制内核、企业级高可用、企业级高可靠、企业级安全、企业级扩展以及企业级智能运维。通过使用腾讯云数据库 MySQL，可实现分钟级别的数据库部署、弹性扩展以及全自动化的运维管理，不仅经济实惠，而且稳定可靠，易于运维。