大话去哪儿网备份恢复平台

来源：http://mp.weixin.qq.com/s/ldu7iS5c3d0ND3foPYoLXQ

作者简介：许子文

曾任达梦高级数据库工程师，现任去哪儿网高级DBA，负责MySQL 、Hbase运维和自动化运维工具的开发。在RDBMS拥有多年数据库架构设计、性能优化和运维经验，对海量数据有丰富的运维经验和个人见解。

备份恢复是DBA日常运维工作中的重中之重􏰀怎么快速高效完成备份和恢复􏰀怎么有效平衡DB数据量和业务重要等级􏰂接下来从技术和业务的角度介绍Qunar数据库备份恢复平台的演变过程和经验分享􏰂

1.HA

说到DBA􏰀每天都要和数据打交道􏰀在数据就是金钱的时代如何预防由于软硬件故障或其他原因导致数据的损坏一直是个热点话题􏰂根据墨菲法则􏰃凡事只要有可能出错􏰀那就一定会出错􏰂那对于掌管企业数据命脉的DBA来说􏰀避免数据损坏的备份恢复是DBA工作的重中之重业内关于高可用有一个HA标准􏰀关于可用性分级􏰂9越多说明越容错􏰀可用性越高􏰂举个例子􏰀5个9的算法是系统1年内服务中断维护了5分钟􏰀那HA可用率􏰅1年/(1年􏰆5分钟)􏰂数据这么重要􏰀没有备份某种意义上可以说其实HA􏰅0􏰀在qunar数据的高可用一直是个重要的话题􏰂

数据的高可用􏰀从MySQL高可用方案有最简单的MS主从复制􏰀有强一致性的PXC􏰀有基于半同步􏰆GTID􏰆分布式哨兵的QMHA􏰀这些保证了MySQL高可用的同时也保证了数据的高可用􏰂那么从备份来说􏰀备份的手段很多􏰀常说的名词有冷备􏰁热备􏰁物理备份􏰁逻辑备份􏰁本地备份􏰁远程备份􏰁全量和增量备份以及LVM快照备份􏰁跨机房容灾备份。

2.备份恢复介绍

备份手段多种多样􏰀我们怎样把控到位􏰀找到属于自己的备份之道呢􏰄首先从备份恢复的分类开始说起,分模块化进行对比找问题􏰂

2.1 备份

根据备份时数据库的状态可以分为冷备份和热备份􏰂 。

冷备份也叫离线备份􏰀需要停机进行数据文件拷贝􏰀DB服务中断业务受损,冷备份是操作最简单但是最不可取的备份手段􏰂因为是直接拷贝数据文件,冷备的恢复无法解决数据空洞的问题􏰀同时在跨平台进行恢复需要考虑系统版本􏰁文件大小写敏感和浮点数格式等因素􏰂热备份也叫在线备份􏰀服务不需要停机􏰀对业务影响极小􏰀通常业内的备份也是围绕着在线备份展开􏰀也是我们主题的重点􏰂

根据备份文件内容的差异可以分逻辑备份和物理备份􏰂

逻辑备份通常是将数据导出为可执行可读的SQL文本文件􏰀备份恢复速度慢􏰀是sql layer层得到的sql语句􏰂适合于数据量小的实例􏰂通常作为DBA运维的辅助工具􏰀例如备份表􏰁表结构􏰂

物理备份是指对物理文件进行的拷贝􏰀通过拷贝日志文件和数据文件􏰀在数据文件应用日志进行前滚和回滚来达到数据备份的一致性􏰂备份恢复时间相对于逻辑备份效率要快很多􏰂

日常实际运维工作中实际的备份手段也是逻辑备份和物理备份结合使用。那么MySQL相关的常用逻辑备份工具有哪些呢？

a)官方的mysqldump,单线程的逻辑备份工具

b)开源的MySQL多线程逻辑导出工具mysqldumper ,行纪录级别实现并行备份。主线程切分chunk，按chunk进行导出。

c)5.7推出的并行多线程逻辑备份工具 mysqlpump,该工具多线程的粒度是表，单表依然是单线程导出。

d)sql导出到文本。

从逻辑备份工具由单线程到多线程的演变特点也可以看出，逻辑备份效率慢，遇到实例过大时，逻辑全备就不是一个好的选择了。这时候通常考虑物理备份，那么MySQL相关的常用物理备份工具有哪些呢？

官方企业版本的ibbackup和percona xtrabackup。工具都可以同时备份MyISAM和InnoDB存储引擎表，其本质时对物理文件和日志文件的拷贝。但是两者相比而言，ibbackup是官方企业级收费软件，业内更常用percona xtrabackup工具，它在ibbackup上进行了功能扩展，支持增量备份。

说到增量的问题，备份又可以分为全量备份和增量备份。全量备份很好理解，就是对整个DB进行备份，而增量备份则是基于上一次的备份备份期间有变化的数据页。增量备份分为累积增量备份和差异增量备份。增量的备份依赖于最近一次的全量备份，恢复时同样依赖于全量恢复和增量备份应用,不便于管理，虽然增量备份能够减少备份数据的大小、加快备份的效率，但是管理较全量备份更加麻烦，Qunar DBA运维过程中我们采用全量备份＋binlog备份来完成备份需求。

根据备份文件存储位置可以分本地备份和远程备份，简单的说就是在哪里备份以及备份文件存储在哪里？有个容灾标准：任何时候都需要做好远程异地备份。考虑到本地备份存储资源的消耗和容灾标准，Qunar DBA采用远程备份。

2.2恢复

恢复的场景通常是跟你采用的备份方式一一对应的，如果是逻辑备份则直接执行备份生成的sql文本或通过load file来进行数据恢复，如果是物理备份则通过还原物理数据文件并应用备份期间的日志文件进行前滚、回滚来恢复到数据备份时的一致性状态。而当采用的增量备份时，则需要先恢复到最近一次全量备份然后进行增量的恢复。

3.常见问题

备份恢复相关基础知识介绍得差不多，日常运维中大部分DBA常用的备份工具是mysqldump和Percona Xtrabackup，通常DBA的备份恢复体系或平台都是围绕这两个工具进行展开。那面对成千上万台db实例的维护，业内备份恢复有哪些问题呢？

a)本地存储备份,磁盘空间double，不仅造成资源的浪费而且由于资源消耗放大了备份对线上业务的影响。

b)备份手段很多,每个dba有自己的爱好。没有集中化管理，而是多样化进行备份，维护困难。

c)备份文件校验,备份文件不做校验通常是最大问题也是最容易忽视的问题，以为备份完成就成功了，出现恢复时发现备份文件无法恢复的问题。

d)集群备份节点选择问题。备份或多或少对线上业务都有影响，DBA建议备份部署在slave或statistic节点上，那么当集群发生主从切换,如果备份节点没有动态进行切换，导致在写库上进行备份，使线上业务受备份影响。

e)流量和压缩。同样备份传输引发了网卡流量限速和压缩对线上业务造成CPU、网络的影响不可忽视。

这些都是业内备份恢复的一些常见问题,同样Qunar也是经历了这些问题，接下来聊聊Qunar是怎么在搭建备份恢复平台的路上解决这些问题。

4.Qunar备份恢复

在考虑备份恢复平台的初期，实例数并不是很多，DBA组前期考虑的不是快速搭建一套可用的备份恢复方案，更多的是考虑方案是否能够易扩展，达到100台能完成备份恢复，1000台及更多也能轻松完成备份恢复。所以在设计的时候从底层往上设计，充分考虑到日后业务增长实例数变多的情况。因此在Qunar不同的机房内，每个机房都至少单独搭建了1条专用于备份恢复的通道，各机房实例的备份恢复走自身专有的备份通道，各机房之间独立无干扰。在后期随着业务量上涨实例数增多，只需要动态的在相应机房新增通道即可。多通道备份恢复形成了备份恢复平台的骨架，通道内完成备份后按策略将备份同步到备份池。

采用多通道的方式易于扩展，但是备份存储怎么找到一个高可用的易扩展方案呢？

首先DBA组优先确定好两个事情:1)备份文件的存储问题，需要满足多地多机房存储备份文件的硬性指标。2)备份的存储策略：本地无备份、备份通道机存储最近N次备份、历史备份集压缩存储到备份池。基于这两点考虑DBA调研后采用MFS备份池， MFS是一种容错的分布式文件系统,将数据切分成多个数据副本存储在不同的计算机节点里，备份文件的高可用性极大的得到保证。虽然MFS由很多计算机组成，但是访问文件时跟Linux常见文件系统操作一样，底层对使用方透明、访问友好。随着备份文件的日积月累，MFS很方便的动态通过增加廉价计算机来进行磁盘扩容。同时MFS一个深受欢迎的特点是延迟删除，删除文件并不会实时删除，而是放在回收站里面暂存。Qunar设置的备份文件清理是延迟1天删除，防止误删操作。

备份恢复多通道、存储MFS都是为了日后方案满足易扩展的特点，那么真正采用何种方法来进行线上实例的备份恢复呢？

Qunar前期是通过mysqldump来完成实例的备份，但是mysqldump效率慢，单实例过大造成白天业务高峰期还在进行实例备份,备份导致的资源消耗造成备份节点复制延迟、PXC节点限流的情况。由于这些因素DBA逐渐采用效率更快的Percona Xtrabackup物理备份，通过流的方式备份到远程备份机。考虑到备份时长和文件大小，前期也考虑过增量备份，但是由于增量备份在进行恢复时需要依赖最近一次全量备份，备份文件不便于管理，DBA操作不易于恢复。同时如果采用增量备份，实例就无法采用流的方式进行远程备份。综合考虑DBA抛弃增量备份，统一采用Percona Xtrabackup全量备份。另外Percona新增了备份恢复相关的锁优化，极大降低了备份时对线上实例的影响。

实例备份的影响不能被放大，需要对线上业务透明。DBA通过两个方法来进行优化，一个是备份任务划分成多个任务队列并行备份,在业务高峰期前完成备份任务，多通道的设计此时可以很好的隔离各个通道的备份任务。一个是备份资源和线上资源隔离，统一采用专用备份网卡，因此DBA组要求所有线上实例均需要部署备份网卡。通过多任务备份队列、专用备份网卡来降低备份对线上业务的影响，达到基本透明。

前期还有一个细节往往被忽视，备份节点选择没有和集群信息实时联动起来。因为备份的影响DBA通常是在读节点或离线节点进行数据备份，当集群维护发生主从切换，因为信息未联动起来造成原来部署有备份任务的读节点变成写节点来进行备份，放大了备份对业务的影响。Qunar DBA明确要求备份任务部署到读节点，备份任务开启时对集群节点进行角色检测，当集群发生切换导致节点变化，备份节点会自动切换到实时读节点上进行备份。即保证备份永远只会在读节点进行备份任务发起。

备份文件的校验是DBA特别关注的一个点，不希望存在备份文件无法恢复的场景。因此在备份过程中备份文件提前通过apply log进行了恢复，即达到了备份文件的校验同时又加快后期备份恢复的速度。因为事先已经提前apply log，在真正需要恢复时只需将物理数据文件拷贝到指定位置授权启动实例即可。因此Qunar的备份任务只有在备份完成并且apply log成功后才能真正标记此次备份任务成功，否则失败重试。

备份恢复的雏形完成后开始编写后台脚本实现功能需求，经过一段时间后台脚本运行的验证,需要集中同一套后台代码程序兼容不同mysql版本、不同高可用架构的定时备份，即集中统一管理，无特例个性。当手动操作变得规律性、完整性、正确性，DBA开始希望能够有平台统一集中管理备份恢复调度，通过界面可视化操作。DBA开始将备份恢复功能集成在DBA开发的DUBAI平台里面，整个平台后端使用python、shell语言编写，web前端页面使用tonardo实现。利用DUBAI平台很轻松的面对大量MySQL 实例的备份恢复管理，可视化配置部署及进度信息展示。

当DUBAI平台备份恢复上线后，备份恢复工作变得简单。当集群新上线或变更时DBA在DUBAI平台进行备份任务部署，部署前提有一个指标检查：是否部署专用备份网卡。任务配置后台入库，配置中心根据任务信息定时向中控机发起备份任务，中控机远程向实例调度备份以流的方式向同机房备份机传输，任务结束后逐一向上层返回任务状态信息，最终在DUBAI平台进行界面信息展示。同时备份文件会在同机房备份机进行压缩，以RSYNC的方式同步到MFS备份池。至此，一次备份任务完成。DBA只需要部署备份任务、查看任务状态即可，不再需要过多的人工介入备份任务中。

恢复相关，DBA整理出运维工作中常见的恢复需求：1)通过备份文件新建实例 2)通过备份文件新建SLAVE 3)指定时间点恢复 4)闪回。闪回需求只要是通过INCEPTION平台操作很容易得到回滚语句进行闪回。因此Qunar DBA常见的是前三种恢复需求。备份的基础数据非常完善，对基础数据加工便能方便快速的针对恢复需求进行功能实现。由于统一采用全量备份，因此指定时间点恢复是在全量恢复的基础上进行BINLOG的应用来实现指定时间点的恢复需求。

至此备份恢复平台主要骨架搭建完成，通过这个平台DBA运维过程中依然发现一些问题：备份时间过长、恢复时间过长。其问题根源在于单实例数据量过大、冷数据过多、备份策略过于统一导致。实例数据量过大的解决方法是DBA通过实例拆分、大表拆分来解决，将不同业务的库拆分成多个实例，严格控制单个实例的数据量大小，对于大表进行拆分(如按月拆分成月表)方便运维。冷数据过多的解决方法是DBA引入了服务分级策略，将线上服务分为一级服务和二级服务，一级服务的冷数据定期归档到二级服务，二级服务只保证高可用不再进行备份,服务分级的思想融汇于拆分工作中。备份策略过于统一的解决方法是DBA深入业务线，对各自业务进行服务分级。服务分级直接决定实例的备份策略，做到能少备份的不多备份，不需要备份的不进行备份。基于三个问题，DBA逐一解决后开始了对备份恢复平台的功能扩展。

二级服务的理念诞生数据归档工具，一级服务的热数据通常集中在最近一个月、三个月乃至一年，对于不需要进行备份、降低运维需求的冷数据希望通过数据归档工具定期归档到二级服务库，这个库可以是历史库、可以是线上库、可以是hbase等。DBA针对各个业务的一些归档需求进行总结细化，开发出数据归档工具来完成一级服务和二级服务数据的流动。