vivo互联网领域拥有的数据库组件分别为 MySQL、MongoDB、TiDB 等，其中MySQL集群占比绝大部分，  MongoDB 集群占比小部分， TiDB 集群占比更小。为了介绍方便，本文把改造前的数据库备份恢复系统称为旧备份恢复系统，改造后的数据库备份恢复系统称为新备份恢复系统。我们将从旧的架构系统开始，发现其不足，慢慢的优化形成新的系统架构。

旧备份恢复系统架构图

旧备份恢复系统是基于Python 语言开发的，使用分布式文件系统GlusterFS，Python作为开发语言，使用任务调度模块Celery下发备份和恢复任务。或许由于之前开发时间紧迫，在服务可用性和Redis组件高可用性上，并未做过多的工作。若出现物理机宕机或网络等问题，将直接影响备份系统的稳定性。

2.1 备份模块

备份模块是旧备份恢复系统的一个主要功能服务，主要用于MySQL、TiDB、MongoDB 组件的备份调度、备份等任务，来完成每日的数据库备份。旧备份恢复系统主要使用的是逻辑备份，在仅有5台物理机上负责备份任务的发起和执行，由于互联网的体量大，数据库全备一次需要2天的时间，因此备份的成功率是按照2天统计。由于文件系统的高负载，以及备份中锁等原因也会出现备份调度失败的情况，导致整个物理机上的实例不能再次发起备份，需要手工维护才能继续备份，系统维护上也非常麻烦。

2.2 组件备份介绍

MySQL和TiDB的备份

Mydumper 是一款社区开源的逻辑备份工具。该工具主要由 C 语言编写，目前由 MySQL 、Facebook 等公司人员开发维护。

参考官方介绍，Mydumper 主要有以下几点特性：

Mydumper的主要工作步骤：

基于Mydumper 以上的特性，PingCAP公司针对 TiDB 的特性进行了优化，Mydumper 包含在 tidb-enterprise-tools 安装包中。对于 TiDB 可以设置 tidb_snapshot 的值指定备份数据的时间点，从而保证备份的一致性，而不是通过 FLUSH TABLES WITH READ LOCK 来保证备份一致性。使用 TiDB 的隐藏列 _tidb_rowid 优化了单表内数据的并发导出性能。TiDB 官方早起提供了Mydumper备份工具，后期提供了BR 物理机备份工具，然而物理机备份受限制于文件系统，在GlusterFS 文件系统下，只能使用Mydumper 做逻辑备份。

Mydumper 备份属于逻辑备份，需要读全表，因此备份效率会低很多。同一个数据库，在文件系统不变的情况下，逻辑备份和物理备份的对比。

从该统计可以看出，逻辑备份时间很不稳定，Mydumper 备份最短一次是6.5个小时，最长在23小时，而物理机备份时间基本维持在7个小时左右。

Xtrabackup是Percona团队开发的用于MySQL数据库物理热备份的开源备份工具，具有备份速度快、支持备份数据压缩、自动校验备份数据、支持流式输出、备份过程中几乎不影响业务等特点，是目前各个云厂商普遍使用的MySQL备份工具。

由于物理机备份未使用压缩和打包，备份的文件受限于表的大小，在备份特别大的表时，总会出现文件系统分布不均匀的情况，大部分磁盘在80%的时候，某些磁盘的使用容量却超过95%，需要经常登录文件系统删除备份文件来消除告警。另外物理备份配置比例较小，备份占比不高。后续虽然经过一些了优化（增加打包和文件分拆功能），解决了磁盘分布不均的问题。但备份成功率提升不明显。

mongodbdump 是MongoDB 官方提供的备份程序，对于小于100G以内的备份还能轻松应付，但对于大于100G的实例虽然也能备份，不过备份时间会比较长。vivo目前有几十个大于1T的实例，备份难度可想而知，备份成功率很低。有些MongoDB 实例因为太大，导致从未成功过。2天的备份成功率基本在20%左右，哪怕统计一周的成功率也无法达到40%，大于1T的MongoDB 实例，因为文件系统过慢，总是出现备份一半就出现失败，虽经过多次优化，哪怕是把备份盘放置本地盘，再拷贝至文件系统，虽然备份成功率有所提高，但成功率依旧很差，而且还需要经常手工维护。

2.3 恢复模块

2.4 文件系统

A机房的文件系统主要挂载至备份恢复的主控机上，并且A机房文件系统也会挂载到需要物理备份的物理机上。数据库的物理机任何DBA人员均可登录，只要登录该机器上，便可以操作任一备份文件，这对于备份文件是十分危险的；由于A机房是单机房，存在单机房故障的可能，基于以上两点，B机房就应运而生了。

B机房的文件系统只挂载至备份恢复机器的主控机上，并且把A机房的备份文件拷贝至B机房，同时管控备份恢复的主控机权限，便可以确保备份文件系统的安全性。基于此，备份恢复主控机及B机房物理机权限只有2个人有权限访问，从而确保备份文件的安全性。

2.5 Copy 模块

2.6 旧备份恢复系统存在问题

1. 效率不足

2. 旧功能不足

3. 文件系统方面

② 文件系统压力较大，文件系统已经不堪重负

③ 异地灾备形同虚设

• 受文件系统读写的限制，异地灾备的文件系统存储的都是几天之前的备份文件

基于Python开发的旧备份恢复系统存在许多缺点，最后引入Java 开发人员和对象存储，对备份系统进行全方位的改造，经过一系列改进，互联网领域目前的备份系统架构图如下：

3.1 新备份恢复系统效率的提升

新备份恢复系统改善

Redis 系统终于从主从版本改成Redis cluster 集群版本，Redis可用性得到很大的提高。

1. MySQL备份效率提升

目前备份系统的命令使用方式是

baseDir = fmt.Sprintf("/data/mysql%d", port)args = append(args, fmt.Sprintf("--defaults-file=%s/conf/my.cnf", baseDir))args = append(args, fmt.Sprintf("--datadir=%s/data", baseDir))args = append(args, fmt.Sprintf("--socket=%s/run/mysql.sock", baseDir))args = append(args, fmt.Sprintf("--user=%s", user))args = append(args, fmt.Sprintf("--password=%s", pwd))args = append(args, "--slave-info")args = append(args, fmt.Sprintf("--ftwrl-wait-timeout=%d", 250))args = append(args, fmt.Sprintf("--open-files-limit=%d", 204800))args = append(args, "--stream=xbstream")args = append(args, "–backup")args = append(args, fmt.Sprintf("--parallel=%d", parallel))args = append(args, fmt.Sprintf("--throttle=%d", throttle))args = append(args, "–compress")
增量备份args = append(args, fmt.Sprintf("--incremental-lsn=%s", incrLsn))

每次备份，我们会主动获取incremental-lsn，为下次增量备份做准备。

2. TiDB 备份效率提升

TiDB 官方提供了br 物理机备份工具，加上物理机备份与文件系统结合，备份效率也得到的大大提升，目前TiDB 4.0 以上的版本使用物理机备份+ 增量备份，需要设置gc_time 为48h，否则增量备份会报错。而对4.0以下的版本继续使用Mydumper进行备份。

3. MongoDB 备份效率提升

由于mongodbdump 逻辑备份对数据量大的实例备份十分困难，因此引入了MongoDB的物理备份。

db.fsyncLock() 特性

Changed in version MongoDB: 3.2db.fsyncLock() ensures that the data files are safe to copy using low-level backup utilities such as cp, scp, or tar. A mongod started using the copied files contains user-written data that is indistinguishable from the user-written data on the locked mongod.Prior to MongoDB 3.2, db.fsyncLock() cannot guarantee that WiredTiger data files are safe to copy using low-level backup utilities.

增加隐藏节点cfg = rs.conf()cfg.members[2].priority = 0cfg.members[2].hidden = truecfg.members[2].votes = 1 rs.reconfig(cfg)

隐藏节点需要具有投票，这样可以减少一个实例节点。

使用db.fsyncLock() 锁库获取最新的oplog位置next_ts=db.oplog.rs.find().sort({$natural:-1}).limit(1)tar -cf 文件使用 db.fsyncUnlock() 解锁

记录oplog 位点是为了增量备份做准备

增量备份是备份oplog，根据全备获取的最新的oplog 进行备份使用db.fsyncLock() 锁库last_ts=db.oplog.rs.find().sort({$natural:-1}).limit(1)mongodump --host= 127.0.0.1 --port=27010 --username=mg_backup --password=123ASD123 --gzip --authenticationDatabase=admin -d local -c oplog.rs \-q '{ts:{$gt:Timestamp("next_ts")}}' --archive=oplog.inc_2使用 db.fsyncUnlock() 解锁

因此，备份逻辑上也进行了改造，对于 小于20G的实例，使用mongodbdump逻辑备份，对于大于20G 的实例使用物理机备份。由于物理机备份直接拷贝物理文件，备份速度快了很多。而逻辑增量备份是备份oplog，oplog设置基本都在50G左右，因此逻辑增量备份也能满足需求。

① 全备恢复

tar -xf bull_back -C xxxx

使用空实例，不直接接入之前的副本集中

② 增量恢复

mongorestore --archive=65.gzip --port=11303 --gzip --oplogReplay

物理恢复主要用于MongoDB的定点恢复，日常添加从节点，都是使用MongoDB自身的数据同步。由于MongoDB 在公司占比份额较少，而且出现误删数据的几率也小，自维护MongoDB 依赖，仅仅出现过2次MongoDB定点恢复的案例。

4. 性能提升总结

3.2 文件系统演化

文件系统使用的是vivo资源的对象存储系统。vivo对象存储提供海量、安全、低成本、高可靠的云存储服务，提供12个9的数据持久性，99.995%的数据可用性。提供多种语言SDK，开发者可快速便捷接入对象存储。

• 服务稳定可靠：提供12个9的数据可靠性保障。
  

• 存储空间大：提供PB级存储能力，存储空间按需扩展无上限；单个Bucket的容量无限制，单个文件（对象）最大支持48.8TB。
  

• 成本低：根据不同数据类型选择选择不同性能存储规格降低服务器成本，通过纠删码、数据删重、压缩等技术节省存储空间。
  

• 数据安全有保障：支持桶和对象级别的权限控制，通过防盗链、多种加密方法保障数据安全。
  

• 使用便捷：可通过SDK、控制台进行上传下载。

经过一系列的改造，备份效果得到了大大的改观，使用对象存储以后，基本不再考虑文件系统的压力及高可用性，省去了很多麻烦。而且对象存储无法直接查看和操作备份文件，文件的获取均需要程序操作，任何人员无法直接获取，增加了文件安全性。

3.3 备份系统功能扩展

1. 中转机组件

2. 恢复模块

3. 备份校验模块

备份校验模块是为了验证备份文件的有效性做的一个模块，为了实现这功能，我们设计了两套方案。

恢复实例+10分钟同步验证，如果10分钟同步主库无报错，就认为备份文件是有效的。但会消耗至少一个MySQL实例资源，同时要较久的同步时间和一致性校验时间，落地有成本和效率问题，本方案未采用。

目前使用的备份校验标准：

① 设定备份流程：

② 备份恢复流程：

我们为了保障核心数据库的备份文件有效性，特设定了以下标准：

4. 定点恢复模块

定点恢复模块主要应用于误删数据后的恢复工作，该系统的架构图如下：

首先，需要与开发人员沟通误删数据时间点，从主库中寻找对应的binlog 位点，或者是gtid信息，并在我们的内部管理系统daas上的【备份管理】中选择出指定的备份文件，并在daas管理系统提数据恢复工单，工单界面图如下：

5. 自动化迁移模块

自动迁移模块是基于备份文件实现的，vivo的MySQL组件使用的是物理机混合部署，磁盘使用的是4T的nvme 盘，因此会受到磁盘容量的影响。我们是多实例部署，共享cpu，内存，磁盘空间。随着业务的增长，磁盘使用容量会慢慢的增加，我们目前设定磁盘使用88%时，便自动提单迁移实例。之所以选择磁盘使用率的88%，是因为我们的报警是从90%开始，主要是为了降低磁盘方面的告警。

• 提高物理机磁盘使用率

• 减少DBA人工迁移的工作量

• 提高迁移效率

• 单个工单形成扩容、主从切换、域名切换、回收的闭环

• 从库优先迁移

• 磁盘使用率10%左右的优先迁移

• 实例资源小于100G的不迁移

获取满足需求的物理机: 满足 【物理机磁盘使用率】+ 【迁移实例磁盘使用量】 小于物理机磁盘使用率80%   

流程图如下：

自动化迁移工单图

3.4 新备份恢复系统的不足

1. MongoDB shard 备份缺陷

由于MongoDB shard 引入，MongoDB shard 备份还未有更好的备份方案。目前MongoDB shard 依旧是使用物理备份，但是对数据恢复上还存在不足。在恢复至某一个时间点上，还需要使用oplog单独对每个分片进行恢复，恢复起来步骤复杂。

2. 数据恢复效率不高

数据恢复是在数据被误删的时候发起的操作，虽然使用频率较低，但是该功能却是非常重要的，目前恢复数据是基于全库恢复+binlog重做，恢复效率较低，依旧有很多的恢复方案亟待加入，提高恢复数据的效率，减少因误删数据产生的影响。

4.1 安全

4.2 效率

4.3功能模块扩展

自从使用Java 语言后，并且有专门的 Java 开发人员的介入，新功能需求得到了实现，经过多轮的优化，目前新备份恢复系统运行非常稳定。基于备份文件，我们扩展了定点恢复模块、自动化迁移方案、以及机器故障自动发起迁移等功能，极大的提高DBA的工作效率，让我们有更多的时间去解决企业的痛点。