?数据库备份还原系统

　　编者按：《运维之下》一书覆盖了系统、网络、数据库、安全、标准化、自动化等多个层面，从创业初期见招拆招到BAT级别的规模化运维，从PaaS、IaaS到公有云，从运维理念到平台实践，都有所阐述。作者从个人成长经历出发，分享了自己与团队在运维工作发展过程中遇到的问题，如何去思考问题，怎样去解决问题。与其说这是一本传授管理经验和工作秘诀的书，不如说它更是一本关于运维体系化的指导手册。在各种说教式理论类丛书漫天飞的同时，笔者能够耐得住性子，将自己的多年的从业经验，合力共聚为一本书，这本书的含金量自然可想而知。本篇为《运维之下》第二十章。

　　第二十一章：数据库备份还原系统

　　数据是出于用户对公司产品的喜欢和信任，不断创造和提交的。对于公司来说，这是无比珍贵的资产。如果不幸把数据损坏或者弄丢了，会严重地损害用户的权益，有可能导致严重的用户流失。读者可以想象一下，如果facebook的用户数据一夜之间消失了，用户会有什么反应呢？如果说对facebook的体验还不强烈，可以再想象一下，若此时存放着你所有存款的银行突然告诉你，他们把数据弄丢了，而且没法复原，你的银行存款都只能清零，你还能继续淡定地看下面的文字吗？

　　相信通过上面的两个例子你已经理解了数据的重要性，那也就能明白对于整天和数据打交道的DBA来说，数据备份在日常工作中占据了多么重要的位置。对于DBA来说，不怕操作出问题，就怕出问题后没有备份数据进行修复。对数据的任何操作都有风险，一旦出现误操作、数据损坏等意料之外的情况，就可以随时用备份数据把数据恢复到操作前的状态。而如果需要进行数据修复时，却无法找到备份数据进行恢复，这种抓狂和绝望，相信大家或多或少都体验过。

　　为了避免这种虐心的体验，我们把数据库备份还原系统的开发工作放到了第一优先级的位置。经过三个主要的版本开发，备份还原系统已经在生产环境中提供自动创建备份任务、定期进行备份、自动数据恢复测试的功能，保障了业务数据100%的备份成功率和备份数据有效性。本章我们就来介绍数据库备份还原系统的发展过程。

　　为了避免这种虐心的体验，我们把数据库备份还原系统的开发工作放到了第一优先级的位置。经过三个主要的版本开发，备份还原系统已经在生产环境中提供自动创建备份任务、定期进行备份、自动数据恢复测试的功能，保障了业务数据100%的备份成功率和备份数据有效性。本章我们就来介绍数据库备份还原系统的发展过程。

　　单机备份工具

　　我们的第一套备份系统是在每台服务器上单独运行一个备份任务，任务管理都是靠DBA手工进行的，或许这个阶段称之为备份工具会更合适。

　　简单来说，单机备份就是在需要进行数据备份的服务器上安装一个备份工具，比如MySQL官方自带的Mysqldump工具，或者第三方开源的产品Mydumper或Xtrabackup，通过crontab等方式调度，备份数据存储在本地服务器上；需要进行数据恢复时，从存有备份数据的服务器上拷贝一份数据到需要进行恢复的服务器上。

　　单机备份是最简单的一种方式，靠人工来管理备份任务，并需要定期检查备份任务运行是否正常。这种方式上手快，门槛低，所需的开发工作量也很少，适合用在数据库实例比较少、每个实例体量不大的场景下。

　　数据库集群数量少的时候，单机备份方式还能满足日常备份需求，但随着数据规模的扩大，问题就凸现出来了。

　　◎ 备份数据存储周期不长：毕竟是存储在本地数据库服务器上，一般情况下，为了保证数据库服务的IO能力，磁盘都选用高IO能力、低存储空间的高转速SAS盘或者SSD盘，再加上做了RAID，实际可用的存储空间本来就没有多少，如果还要存储几个周期的备份数据，空间资源捉襟见肘。

　　◎ 容易影响数据库运行：因为任务运行和数据存储都与数据库服务在同一台服务器上，每次运行备份任务时，都会同时出现大量的磁盘读/写操作，容易和数据库服务争抢IO资源，影响服务的响应效率；进行数据还原时，拷贝备份数据也会有大量的磁盘读操作，同样也会影响到正在运行的数据库。有的读者也许会说，可以部署一台数据库服务器，专门用来做备份。这样当然可以，不过本着节约的原则，我们还是不推荐这种方式。想想：当你有几百上千个集群时，会有几百上千台服务器专门用作备份，你说这事怎么给老板解释？

　　◎ 维护代价高：靠人工维护，不仅容易出错，而且每次变更调整效率也会有所折扣。另外，由于备份任务零散地分布在多台服务器上，只能靠人工记录任务和服务器的对应关系，正确性难以保证，时间一长，容易出现遗漏或错误。

　　提高备份系统的自动化程度，加强对备份任务的管理，减少DBA在备份管理上的时间投入，这是我们开发第二版备份管理系统的出发点。

　　集中管理备份系统

　　为了便于统一管理和调度备份任务，我们设计了任务管理?？?，把所有备份任务的信息都进行集中记录和维护。管理?？橹饕腥龉δ?。

　　◎ 任务管理：所有的备份任务管理都由任务管理?？楦涸穑梢蕴砑?、删除、修改备份任务，或者激活、停止某个任务的运行，并记录每一次任务运行的状态，比如什么时候在哪台数据库上启动了备份程序，备份过程运行了多长时间，备份策略是全量还是增量，运行结果是否正常，如果正常，备份数据占用了多少空间等，所有信息一目了然，便于DBA每天对备份任务进行常规检查。

　　◎ 任务调度：通过时间事件来调度备份任务。当时间事件触发某个备份任务开始运行以后，管理程序先在本机开启一个TCP端口，用于接收客户端发回的备份数据；然后远程调用部署在MySQL服务器上的备份执行程序，执行程序通过Xtrabackup开始数据拷贝，并将备份数据通过流式（stream）发回到备份服务器集中存储。在备份过程中，只有一次数据读取操作，不在MySQL服务器上再次写入数据，减少了对IO的影响。

　　◎ 数据存储：所有的备份数据都通过网络传回管理?？樗诘姆衿魍骋淮娲?，便于进行查找和管理。

　　同时我们设计了任务执行?？椋饕涸鹗凳┍阜莶僮?，完成管理?？榉⑺凸吹谋阜萑挝瘢⒔阜莩隼吹氖莘⑺透芾砟？椤Ｈ绻谥葱泄讨谐鱿秩魏未砦?，执行?？榛够峤砦笮畔⒌纳舷挛姆蠢「芾砟？?，并停止任务运行。对现有开源的备份工具进行比对并结合生产环境情况综合评估以后，我们选择了Percona Xtrabackup作为基础备份工具。Xtrabackup可以实现InnoDB表的无锁在线备份，降低了备份任务对数据库正常运行的影响。Xtrabackup是执行?？榈闹匾槌刹糠帧?/p>

　　集中管理备份系统的结构示意图

　　集中化管理可以有效地提高DBA的工作效率，对备份任务的管理（增、删、改、查）只需要在页面上用鼠标点击几下就可以完成，每天的备份任务运行情况也一目了然。这种方式具有开发量小、管理直观快捷的优点，特别适合用在中等规模的数据库集群中。用户可以通过Web管理页面查看和管理所有的备份任务，如图所示。

　　备份任务管理

　　备份任务运行报表

　　随着数据规模的继续增长，这套系统也逐渐难以满足需求，下面是暴露出来的主要问题。

　　◎ 存储空间饱和：由于所有的备份数据都要传回存储?？榻写娲?，在备份任务数量增多的同时，存储空间的争抢问题变得愈加严重。

　　◎ 并发控制不便：由于备份任务是通过时间事件进行触发的，有可能出现在部分时间区间大量的备份任务一起运行，备份存储服务器的IO压力非常大；而有些时段又没有备份任务运行，资源白白浪费掉了。

　　◎ 无法进行水平扩展：为了便于在备份过程中就将备份数据传回存储?？榻写娲ⅲ挝窆芾砟？楹痛娲⒛？槭钦显谝黄鸬?，导致了严重的中心化，要扩展存储?？榉浅Ｂ榉?。

　　细心的读者可能会发现，由于任务管理模块和调度?？槭钦显谝黄鸬?，而调度?？楹痛娲⒛？橛窒嗷ヒ览?，管理?？榈闹行幕贾铝撕竺媪礁瞿？槲薹ㄗ龅剿嚼┱?，而出现瓶颈的主要是调度?？楹痛娲⒛？?。如果能把任务管理?？榻怦睿杓瞥啥懒⒌囊桓霾糠?，就可以对后两个?？榻欣┤萘??；谡飧鏊悸罚颐嵌缘诙姹阜菹低辰辛烁陌?，把任务管理?？楹偷鞫饶？榉植鹞礁龆懒⒉糠?，并引入了优先级队列，去除了时间事件驱动的方式，形成了第三版备份管理系统——分布调度备份系统。

　　分布调度备份系统

　　第三版备份系统由三层逻辑组成，第一层是任务管理?？椋═ask Manager），和第二版的任务管理?？楣δ芾嗨?，用于管理所有的备份任务和记录元信息；主要的改变就是增加了一个优先级队列。每个备份周期开始时（如每天零时），管理?？榛岣菹钟械乃写τ诩せ钭刺娜挝竦闹匾潭?，生成一个备份任务优先级队列，然后等待处于第二层的调度?？槔辞肭笕挝?。

　　调度模块（Scheduler）的调度策略和第二版不同，放弃了时间事件触发的方式，而是采用了自发请求任务的方式。如果调度?？榉⑾值鼻白约赫谠诵械娜挝袷齆，小于允许运行的最大任务数M，即N

　　执行模块的功能和第二版相同，只负责执行具体的备份操作，没有任何变化。

　　分布调度备份系统的三层结构示意图如图21-4所示。用户可以继续通过Web页面管理和查看备份任务，也可以通过API的方式和管理?？榻薪换?。

　　分布调度备份系统的三层结构示意图

　　第三版备份系统的主要特点如下：

　　◎ 任务管理集中化：所有的任务依然是集中管理，通过Web页面或者API的方式，可以管理和查询所有任务的信息和历史运行状态。

　　◎ 有效的并发控制：每个调度?？槎伎梢愿莘衿鞯呐渲茫髋湓市硗痹诵械娜挝袷?，使备份服务器的压力可控。

　　◎ 方便水平扩展：如果磁盘存储空间不足，则可以通过增加服务器的方式快速扩容，新增加的服务器可以自动注册到任务管理?？橹?，并申请任务运行，管理代价很小。

　　◎ 数据分布存储：备份任务是随机在不同的调度模块（存储服务器）上运行的，每个备份任务的备份数据都会分布在多台服务器上，如果其中一台存储服务器挂掉了，损失的也只是一部分备份任务的某几次备份数据，不会出现某个任务的全部备份数据丢失的情况。

　　◎ binlog备份：前面介绍的备份都是某个时间点的数据镜像，如果需要恢复到任意时间点，就需要使用binlog。在第三版备份系统中，支持binlog备份的需求。当用户添加了一个日常备份任务以后，备份系统通过获取数据库实例的复制信息（Slave status），找到当前实例的上级主库（或者主库就是该实例自身），然后在备份服务器上启动一个程序，模拟成数据库从库，向主库实时同步binlog任务，达到更新数据实时备份的目的。

　　◎ 自动数据还原：由于任务管理?？榧锹剂怂斜阜菔莸男畔ⅲ庑┬畔⒕涂梢杂美词迪肿远乖?。自动还原过程类似于备份过程，只不过数据传输方向是相反的。当用户发起一次数据还原请求时，备份系统会找到一份符合条件的备份数据，并将数据发送给需要恢复的目标服务器，进行恢复操作，如果有需要，还可以自动建立新实例和主库的复制关系，完成数据恢复过程。另外，结合binlog备份，可以恢复数据到任意时间点，供DBA或者研发人员分析、测试使用。

　　◎ 自动恢复测试：备份系统会周期性地对备份数据进行恢复测试，检验备份数据的可用性和正确性，如果发现异常，会及时通知相关的负责人员。对备份数据定期进行恢复测试，可以有效地保证备份数据的正确性和有效性，确保在需要的时候能有一份可用的数据副本。

　　总结

　　本章介绍了数据库备份还原系统发展的主要历程和现状。备份还原系统共经历了三个大版本的发展，从最初的单机备份，发展到目前在役的分布调度备份还原系统，实现了备份管理自动化、任务调度自动化和可扩展、数据恢复测试自动化等重要功能。在保证数据备份覆盖率和成功率的同时，有效地提高了DBA的工作效率，减少了人工操作的时间投入和误（漏）操作的数量。

　　更多精彩内容技术头条将持续跟进，第一时间为大家送上最新动态~o(^▽^)o

　　请扫描以下二维码关注技术头条公众号更多精彩内容将在技术头条持续发布，敬请关注！微信号：jishutoutiao