大话Qunar数据库备份恢复

　　互联网企业级数据库的 HA 可用水平分成几个等级，如下：

　　目前我们 Qunar 数据库提供99.99%服务，即全年的宕机不可服务时间要控制在53分钟以内，这对 DBA 来说是个挑战，我们需要通过 MySQL 的高可用架构设计来达到，当然也需要针对数据库进行备份。

　　Qunar 的 MySQL 高可用架构有 MMM，PXC 和 QMHA，其中 PXC 和 QMHA 是自主开发设计的架构，对外提供 namespace 服务，在强一致性、性能和跨机房服务间做权衡。

　　常用的数据库有热备份和冷备份，热备份又分为物理热备份和逻辑热备份，各种备份方式都有优缺点，企业需要根据自身的服务特点和需要进行选择。互联网企业一般都选择热备份，Qunar 也是。

　　备份恢复方式

　　优点

　　缺点

　　热备份(online backup)

　　物理热备(InnoDB ibbackup、Percona XtraBackup)

　　速度快

　　MySQL版本绑定

　　逻辑热备(mysqldump、mysqlpump)

　　简单、备份样式可选

　　sql语句,备份恢复速度慢

　　冷备份(offline backup)

　　操作简单、拷贝数据文件

　　a.DB服务中断业务受损

　　b.无法解决数据空洞问题

　　c.冷备恢复存在系统版本文件大小写敏感和浮点数格式等问题

　　Qunar 利用的是 Percona 公司的 Xtrabackup 产品，进行封装和自定义一些其他功能，我们就要讲讲 Qunar 热备份的特点。

　　各个互联网公司在备份方式都有这样那样的问题。

　　1本地存储备份

　　这种备份方式占用本地磁盘空间和 IO，磁盘消耗大，比如数据库500GB，那备份也要占用500GB，这样磁盘容量就要翻倍，这是一种浪费。恢复时也要将备份集传输到对应机器上，这样会占用线上数据库服务器的网络带宽，会影响数据库的正常业务访问。

　　2备份方式选择

　　有些公司的备份种类繁多，不容易管理维护。

　　3非集中管理

　　DBA 部署之后不知道哪个集群有备份，哪个集群没有备份，备份类型是啥，这些都不利于维护管理，有可能会造成很严重的问题。

　　4备份文件校验

　　很多公司就是每次备份完成就认为万事大吉了，但刚做的备份真的有用吗，如果恢复时无法使用怎么办。对于数据库备份集的校验是必不可少的。

　　5备份节点选择

　　有些公司刚开始会在 slave 节点上部署备份，但 master-slave 发生切换后备份节点就变成了 master，这样会对业务使用产生影响，比如磁盘 IO 和带宽，这时很多公司都是手动选择新的备份节点，将原备份删除，很麻烦而且还容易遗忘。6流量控制

　　流量控制不好，会导致同一个机器上多个数据库同时备份。我们现在都是单机多实例，如果这些实例同时备份就会对数据库业务产生影响，所以这也是需要解决的问题之一。

　　7备份时间过长

　　由于数据库太大，导致备份和恢复时间变长，故障的时间也响应的变长。当然备份过程中备份程序被阻塞也会使备份时间变长，比如备份时有一个长查询阻塞了 FTWRL 的执行，这样我们需要解决阻塞的问题。备份时数据文件写入的磁盘和网络太慢也会导致备份时间延长。

　　好了，说了这么多备份恢复容易出现的问题，Qunar 是怎么做的呢？

　　Qunar 备份在每个机房都有一个 backup 角色的机器，用于存储本机房内 MySQL 数据库的备份，然后再传输到远端的备份池 MFS。如图：

　　针对单个机房的备份就是，备份节点执行备份，流方式传输到本机房的 backup 上，然后再根据备份策略将过期的备份集传输到 MFS 备份池，这样就解决了本地存储备份集的磁盘容量问题。如图：

　　Qunar 的备份任务会采用专用的备份网卡，这样不影响业务访问数据库，且同一个备份节点上的实例不会同时进行备份，备份任务都是独立的。如图：

　　在 DBA 的 DUBAI 管理平台上管理各个实例的备份情况，包括备份开始时间，结束时间，备份策略，保留方案，备份节点，上次备份时间，是否成功等信息。备份任务由后端程序统一调度分配，备份程序不使用 agent 或者 crontab 的方式，故备份程序都是一致的且容易管理。如图：

　　每次备份完成后都会对备份集做一致性恢复，确保备份集文件可用。如图：

　　下面是 Qunar 备份整体的任务流程图。

　　综上，Qunar 的备份有如下特点：

　　1、封装 Percona Xtranbackup 全量备份。

　　2、binlog 备份作为增量备份，且 binlog 备份节点与热备份节点同步选择，可以保证增量可用。

　　3、流备份——stream=tar，本机不保留备份集。

　　4、远程存储备份集，backup 角色机器，以及远端 MFS 存储。

　　5、自动选择备份节点，standby 或者 statistic，无视主从切换。

　　6、独立的备份网卡，不占业务带宽。

　　7、备份完成即一致性恢复，保证备份集逻辑上可用，备份集处于一致性状态。

　　8、MFS多副本模式，保证备份集物理损坏仍然可用。

　　9、集中式后台管理、调度，并发可控，状态监测，抛弃了 agent 和 crontab。

　　各个实例备份任务执行情况。如图：

　　添加备份任务。如图：

　　单个集群的备份详情和备份集信息。如图：

　　自动化恢复，根据需要填写要恢复的集群和目标机。如图：

　　好了，到此 Qunar 的备份恢复都讲述完了，当然我们也有一些需要完善的地方，包括 binlog 的恢复，这样可以自动化做到基于时间点的恢复。不过我们已经解决了很多公司遇到的备份恢复问题，希望大家有更好的建议和意见来与我们沟通，谢谢大家！

　　公告通知

　　一场 React Native 技术大会即将举办，欢迎参加！

　　《YMFE Conf 2017: React Native 应用与实践技术大会》 将会于十月中旬在北京举办，届时将有各知名互联网公司移动前端技术达人们来分享交流 React Native 在各自公司的应用与实践。大会门票目前正在火热开售中，扫描下方二维码浏览YMFE CONF官网并购票。

　　扫码浏览 YMFE CONF 官网

　　扫码购买 YMFE CONF 门票