vivo手机备份恢复失败怎么办（vivo手机怎么恢复备份） - 原点资讯

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

新备份恢复系统改善

Java 语言 Redis cluster

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

1. MySQL备份效率提升

【备份工具】：Mydumper Xtrabackup

【备份方式】：逻辑备份物理机备份

【备份策略】：备份不再受限于文件系统的影响，为了快速备份、对于数据库data目录存储大于20G使用物理备份，小于20G的使用逻辑备份。

【备份时间】：00-10 之间就能完成当天的备份，大大的提高了备份效率。

在互联网领域数据库新的备份系统中，MySQL备份恢复采用的是逻辑备份与恢复、物理备份与恢复并存的模式，根据集群大小区分逻辑备份与物理备份。逻辑备份与恢复采用的工具是Mydumper 和 myloader，物理备份采用的是对Xtrabackup进行包装过的工具Xtrabackup_agent（主要是对备份文件上传至对象存储以及恢复从对象存储下载备份文件进行包装以及流式备份的包装）。

物理机备份在最后阶段会获取整个数据库的元数据锁，在日常的备份过程中经常会出现waiting_for的告警，经分析得知，大数据在对特定的表采集时，未释放元数据锁，而新的采集又要获取被备份系统已经持有的元数据锁，因此夜间的备份会告警出来，影响值班人员的休息，而且由于大数据采集SQL因为非常慢，经常与备份产生冲突，为了避免该冲突，备份增加 --ftwrl-wait-timeout参数，为了减少waiting_for的告警，目前的设置并不能避免waiting_for的告警，还需要优化慢SQL语句，才能做到治标治本。

--ftwrl-wait-timeout

指明执行flush tables with read lock前的等待时间，0表示不等待直接执行锁表命令，单位是s，若超过此参数设置的时间后还存在长时间执行的查询，则Xtrabackup终止运行。

--ftwrl-wait-threshold

show processlist 中的 SQL 执行时间，如果SQL 自行时间小于ftwrl-wait-threshold设定时间，直接执行flush tables with read lock 命令，如果SQL 执行时间大于ftwrl-wait-threshold设定时间，则等待。

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

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 备份效率提升

【备份工具】：Mydumper、br工具

【备份方式】：逻辑备份物理机备份

【备份时间】：00:00-10:00

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

3. MongoDB 备份效率提升

【备份工具】：mongodbdump cp

【备份方式】：逻辑备份物理机备份

【备份时间】：00:00-10：00

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

物理备份实现逻辑

db.fsyncLock() 特性

Changed in version MongoDB: 3.2 db.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.

db.fsyncLock() 锁住整库后，可以直接对MongoDB 文件进行cp、scp或者tar 操作，因此，利用该特性进行物理机备份。

由于需要db.fsyncLock()需要锁整个库，为了不影响部分业务的读写分离要求，因此需要增加一个隐藏节点，为了节省资源，我们把其中3个副本中的一个副本作为隐藏节点，在任何业务需要时，可以直接转变为非隐藏节点提供服务，副本被设置为隐藏节点后，是不能对业务提供服务的，只做备份使用。

增加隐藏节点

增加隐藏节点 cfg = rs.conf() cfg.members[2].priority = 0 cfg.members[2].hidden = true cfg.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. 性能提升总结

基于备份逻辑及备份方式的改变，备份效率提高很大，未改造前，MySQL两天成功率才能达到98%以上，改造完毕后，MySQL备份基本在10点以前就能完成所有的备份，而且备份成功率能达到100%。

TiDB更改br 物理机备份后，成功率也提升至100%，而版本低于4.0以下的TiDB依旧使用Mydumper备份，但成功率也实现了质的飞跃。

MongoDB自从改成物理机备份后，成功率也提升至100%。虽然MongoDB的备份文件使用率不高，但使用备份文件恢复数据多达6次以上。

3.2 文件系统演化

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

产品优势

服务稳定可靠：提供12个9的数据可靠性保障。
存储空间大：提供PB级存储能力，存储空间按需扩展无上限；单个Bucket的容量无限制，单个文件（对象）最大支持48.8TB。
成本低：根据不同数据类型选择选择不同性能存储规格降低服务器成本，通过纠删码、数据删重、压缩等技术节省存储空间。
数据安全有保障：支持桶和对象级别的权限控制，通过防盗链、多种加密方法保障数据安全。
使用便捷：可通过SDK、控制台进行上传下载。

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

3.3 备份系统功能扩展

1. 中转机组件

MySQL 集群添加实例的流程:先把备份文件从对象存储上下载到目标物理机上、合并解压备份文件、应用日志、启动实例、配置该实例成为主库的从库，添加从库实例完毕。

该添加从库实例功能上线后，我们发现物理机的原住民会突然出现并发执行SQL增加，业务服务访问数据库变慢的情况，经过排查发现:备份文件在合并解压时，会出现严重的io行为，该行为直接影响物理机上的原住民。

为了解决这个问题，增加了中转机，先把备份文件下载至中转机，在中转机上合并解压文件，并把应用日志后的恢复文件通过Linux的pv工具限速，传送至目标机器上，从而不对物理机上原住民产生影响。

2. 恢复模块

恢复模块依旧沿用之前的恢复策略，在增加中转机的情况下，让业务运行更稳定，更安全。

目前恢复模块主要用于增加从库实例，也应用于已经扩展的自动化迁移功能。经备份逻辑的改造，恢复模块相较于旧的恢复模块，在效率、安全性上提升了很多。

3. 备份校验模块

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

方案1

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

方案2

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

① 设定备份流程：

（1）备份开始前，如果是逻辑备份（数据小于20G），获取所有表行数并记录。如果是物理备份，记录/data目录大小

（2）备份结束后，如果是逻辑备份（数据小于20G），获取所有表行数并记录。如果是物理备份，记录/data目录大小

② 备份恢复流程：

（1）备份恢复到某个MySQL实例，物理备份额外要求执行MySQLcheck 确保没有坏的数据表。

（2）校验备份前后库表差异，

一致则要求备份恢复后的库表结构也和备份前后一致。
前后不一致则不校验恢复后库表结构

（3）校验备份前后数据差异，逻辑备份校验表行数，物理备份校验数据目录大小，要求偏差小于10%

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

设定优先级，对特定的数据库设定较高的优先级
必须保障每月验证一次的频率
每个数据库每年必须验证一次

4. 定点恢复模块

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

vivo手机备份恢复失败怎么办,vivo手机怎么恢复备份(5)

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

vivo手机备份恢复失败怎么办,vivo手机怎么恢复备份(6)

恢复位置点，我们有三种选择方式，选择无，及时恢复到某个备份文件即可，不再追binlog，gitd位点是用于开启gtid的数据库服务，binlog位点是应对未开启gtid的数据库服务。在审批人（一般是该项目开发的负责人）通过后，定点恢复模块便对恢复机器下发命令，从对象存储获取指定的备份文件，恢复数据，通过start slave until 命令恢复至指定的位置点。

以下是恢复完成后的工单详情，通过访问目标ip和目标端口来查看恢复的数据。

vivo手机备份恢复失败怎么办,vivo手机怎么恢复备份(7)

定点恢复受限于物理机磁盘限制，因为要应对各种大小的数据库，我们准备了一个非常大的物理磁盘，不过该磁盘是普通的ssd，因此恢复时间上会比较慢。而且恢复时长也跟数据库的备份文件大小有关，数据库越大，恢复越慢。由于MySQL数据库现在使用了物理备份，恢复单个表只能先全库恢复，再追位点，因此恢复效率比较低。如果是基于Mydumper 逻辑备份的，恢复单个表，会非常快速，因为只需要把恢复的表拷贝出来，即可单独恢复。然而目前却无法实现，在备份效率和定点恢复效率上，我们选择了前者。

定点恢复只需要DBA找到具体的恢复时间点，然后配置恢复页面，系统会自动为我们创建实例，恢复至指定的时间点，从而恢复数据。该操作减少DBA的直接恢复操作，并且以此功能作为一个保底的数据恢复，在定点恢复执行的过程中，如果DBA 有其他方案，可以直接使用另外一套方案来恢复，两个方案同时进行，对恢复数据增加双层保险。

目前误删数据还有许多事情可以去做，使用更多的恢复方案提高恢复效率。

5. 自动化迁移模块

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

目标：