本文根据钱芳园老师在〖deeplus直播：去哪儿网数据库自动化升级与稳保之路〗线上分享演讲内容整理而成。
一、背景
备份对数据库系统非常重要。当数据由于人为或意外的原因导致被误修改、误删除时，可能会造成服务显示错误或无法访问，进而给业务造成很多损失。部分情况下我们可以通过服务器上的日志立即进行恢复，但是服务器上的日志不会永久保留。如果需要查看整个库中的数据时，日志恢复就不能满足我们的需求。这时如果有一份合适的全量备份将数据库中的数据恢复到指定的时刻，则业务可以立即恢复，挽回损失。所以备份对数据库系统而言是一项必不可少的功能。
平台老的数据库备份系统采用中转方式进行备份。备份的流程如下：
备份系统在中控机上发起备份任务。
备份系统选取相对空闲的。
备份系统选取合适的。
备份系统在上执行xtrabackup命令，将数据库中的数据传输到。
等传输完成，备份系统再将数据进行打包、压缩，并上传至。
OPS会定期将上的备份文件进行加密，并统一上传至。
老的备份系统在小规模的数据库上运行并没有发现太大的问题，但是随着业务增长，数据库的规模越来越大，备份系统也就暴露出越来越多的问题，有些问题甚至非常严重，会影响到线上数据库服务的稳定性，因此优化和解决这些问题迫在眉睫。
二、问题
经过我们的调研发现老的备份系统存在如下问题：
备份系统依赖ssh服务的稳定性。如果传输中间网络抖动会造成备份批量失败，那就需要清理临时文件，并重传备份。中控机与各个目标服务器之间的ssh连通性非常重要，而中控机上也会有各种各样的服务，这就导致备份任务受到影响的概率比较大。
备份效率比较低，统一限速为30MB/s。由于线上服务器环境比较复杂，高性能的服务器和低性能的服务器共存，并没有针对高性能服务器适配较高的备份速度。
中转服务器存在性能瓶颈。备份过程依赖中转服务器，如果中转服务器磁盘空间不足，则备份将会被推迟，导致备份效率较低。中转服务器的资源也需要进行预分配和回收。随着业务规模的增大，对中转服务器的需求也变大，备份周期也变的越来越大，备份失败的原因超过80%都是和中转服务器相关。
没有对备份文件进行全生命周期的管理。备份系统只是将备份文件传输到MFS存储之后就结束了，由OPS将备份文件上传到对象存储，故不能针对不同重要性级别的备份设置不同的清理策略。
手动恢复效率低下。老的备份系统并没有将恢复做到完全自动化，对象存储上备份文件的下载需要等待OPS完成，才可以进行恢复操作。
备份完成耗时非常长。一个备份从生成到上传到对象存储中间经历太多模块，如果中转服务器出现问题且不可恢复时，那样整个服务器上尚未上传的备份就会全部失效，备份的完整性受到很大的影响，进而会影响后续的恢复时效和可用性。
系统扩展性不足。无论是性能、可用性还是针对不同版本的数据库，老系统均未考虑到扩展性和兼容性。
以上这些问题，不仅会影响数据库备份的时效性和可用性，甚至会影响数据库服务的稳定性和安全性，备份永远是数据库服务最后的护城河，一旦决堤将对业务产生灾难性的后果。
1、分析
通过对上面提到的问题进行综合分析，团队内部总结出了以下两种解决方案：
对老系统进行修复。主要是修复一些严重的bug，但是有的问题难以从根本上解决，而且由于该系统前后经过多人维护，代码风格、逻辑实现不统一，需要投入大量人力去熟悉和修复，成本很高但收效甚微。
重构备份恢复系统。从架构设计上避免老系统的根本问题，并且可以考虑应对未来十年数据库体量的增长。但是在新系统完全接入之前，也需要维护老系统，对其存在的重大bug优先进行修复，确保可用性。
综合考虑成本以及公司未来发展对数据库备份系统的需求，我们更倾向于从根本上解决问题，重构整个备份恢复系统。故针对新系统我们提出了更高的要求，除了避免老系统的各种问题，还要在系统可用性、稳定性、时效性、安全性方面达到一个全新的突破。
1）针对老的备份系统问题
针对老的备份系统存在的问题，我们的设计方案如下：
依赖自动化平台的
