Author: vivo Internet Database Team - Han Chaobing
This article introduces the evolution of vivo database backup and recovery functions, as well as the functional expansion of backup files.
I. Overview
The database components owned by vivo in the Internet field are MySQL , MongoDB , TiDB, etc., of which MySQL cluster accounts for the majority, MongoDB cluster accounts for a small part, and TiDB cluster accounts for an even smaller proportion. For the convenience of introduction, this article calls the database backup and recovery system before the transformation the old backup and recovery system, and the database backup and recovery system after the transformation is called the new backup and recovery system. We will start with the old architecture system, discover its shortcomings, and slowly optimize it to form a new system architecture.
2. Old backup and recovery system
Old backup recovery system architecture diagram
The old backup and recovery system was developed based on the Python language, using the distributed file system GlusterFS, Python as the development language, and the task scheduling module Celery to issue backup and recovery tasks. Perhaps due to the tight development time before, not much work was done on service availability and high availability of Redis components. If physical machine downtime or network problems occur, it will directly affect the stability of the backup system.
2.1 Backup module
The backup module is a main functional service of the old backup and recovery system. It is mainly used for backup scheduling and backup tasks of MySQL, TiDB, and MongoDB components to complete daily database backups. The old backup and recovery system mainly uses logical backup, and is responsible for initiating and executing backup tasks on only 5 physical machines. Due to the large size of the Internet, it takes 2 days to fully prepare the database, so the success rate of the backup is as follows 2 days statistics. Backup scheduling may also fail due to high load on the file system, locks during backup, etc. As a result, the instance on the entire physical machine cannot initiate backup again, and manual maintenance is required to continue the backup. System maintenance is also very troublesome.
2.2 Introduction to component backup
Backup of MySQL and TiDB
[Backup Tool]: Mydumper + Xtrabackup (MySQL)
[Backup method]: logical backup + physical machine backup
Logical backup Mydumper tool
Mydumper is a community open source logical backup tool. This tool is mainly written in C language and is currently developed and maintained by personnel from MySQL, Facebook and other companies.
Referring to the official introduction, Mydumper mainly has the following features :
Supports multi-threaded export of data, faster.
Support consistent backup.
Supports compressing exported files to save space.
Supports multi-threaded recovery.
Supports working in daemon mode, scheduled snapshots and continuous binary logs.
Supports cutting backup files according to specified size.
The data is separated from the table creation statement.
The main working steps of Mydumper :
The main thread flushes tables with read lock and applies a global read-only lock to prevent the writing of DML statements and ensure data consistency .
Read the binary log file name and log writing location at the current point in time and record them in the metadata file for recovery use.
start transaction with consistent snapshot; Start a read consistent transaction.
Enable n (the number of threads can be specified, the default is 4) dump threads to export tables and table structures.
Back up non-transactional tables.
The main thread unlocks tables. After the backup of non-transaction tables is completed, the global read-only lock is released.
Based on transaction dump innodb tables.
The transaction ends.
Based on the above features of Mydumper, PingCAP has optimized the features of TiDB. Mydumper is included in the tidb-enterprise-tools installation package. For TiDB, you can set the tidb_snapshot value to specify the time point for backing up data to ensure backup consistency, instead of using FLUSH TABLES WITH READ LOCK to ensure backup consistency. Use TiDB's hidden column _tidb_rowid to optimize the concurrent export performance of data in a single table. TiDB officially provided the Mydumper backup tool in the early days, and later provided the BR physical machine backup tool. However, physical machine backup is limited to the file system. Under the GlusterFS file system, only Mydumper can be used for logical backup.
Mydumper backup is a logical backup and requires reading the entire table, so the backup efficiency will be much lower. Comparison of logical backup and physical backup of the same database with the file system unchanged.
It can be seen from this statistics that the logical backup time is very unstable. The shortest Mydumper backup is 6.5 hours and the longest is 23 hours, while the physical machine backup time is basically maintained at about 7 hours.
Physical machine backup Xtrabackup tool
Xtrabackup is an open source backup tool developed by the Percona team for physical hot backup of MySQL database. It has the characteristics of fast backup speed, support for backup data compression, automatic verification of backup data, support for streaming output, and almost no impact on business during the backup process . MySQL backup tools are currently commonly used by various cloud vendors.
Since physical machine backup does not use compression and packaging, the backed up files are limited to the size of the table. When backing up a particularly large table, the file system will always be unevenly distributed. For most disks, at 80% of the time, some However, the usage capacity of the disk exceeds 95%, and it is necessary to log in to the file system frequently and delete backup files to eliminate the alarm. In addition, the proportion of physical backup configuration is small and the proportion of backup is not high. Although some subsequent optimizations were made (adding packaging and file splitting functions), the problem of uneven disk distribution was solved. However, the backup success rate is not significantly improved.
MongoDB backup
[Backup Tool]: mongodbdump
[Backup method]: Logical backup
[Backup time]: All-day time period
mongodbdump is the backup program officially provided by MongoDB. It can easily handle backups of less than 100G. However, it can also back up instances larger than 100G, but the backup time will be longer. Vivo currently has dozens of instances larger than 1T. It is understandable that backup is difficult and the backup success rate is very low. Some MongoDB instances are so large that this never succeeds. The backup success rate for two days is basically around 20%. Even if the success rate is calculated for a week, it cannot reach 40%. For MongoDB instances larger than 1T, because the file system is too slow, backups always fail halfway through, even after many optimizations. , even if the backup disk is placed on the local disk and then copied to the file system, although the backup success rate has improved, the success rate is still very poor, and frequent manual maintenance is required.
2.3 Recovery module
The recovery module is also developed based on Python. The Celery module schedules the recovery strategy and selects the corresponding logical and physical machine recovery according to the configured database backup method.
Logical recovery is to directly use the backup file to restore the target database, but logical recovery is very slow. I have done a T database recovery before, and the recovery took about 1 day. However, logical backup is also beneficial. When restoring a single table, you can directly copy the file system of the table and use the myloader program to restore it directly. You can restore a single table very quickly, which is much faster than restoring a single table on a physical machine. . However, the recovery here requires manual operation, and the code does not implement this function. .
Physical machine recovery is to directly use the file system mounting method, directly mount the file system to the target machine, and copy the backup files to the target machine to restore the data. The function is relatively simple. Since the files are copied directly, the recovery speed is relatively slow. Be faster.
恢复模块仅用于增加从库实例和延迟从库，未做到任一时间点的恢复，功能相对单一。
2.4 文件系统
GlusterFS系统是一个可扩展的网络文件系统，相比其他分布式文件系统，GlusterFS具有高扩展性、高可用性、高性能、可横向扩展等特点，并且其没有元数据服务器的设计，让整个服务没有单点故障的隐患。当客户端访问GlusterFS存储时，首先程序通过访问挂载点的形式读写数据，对于用户和程序而言，集群文件系统是透明的，用户和程序根本感觉不到文件系统是本地还是在远程服务器上。读写操作将会被交给VFS(Virtual File System)来处理，VFS会将请求交给FUSE内核模块，而FUSE又会通过设备/dev/fuse将数据交给GlusterFS Client。最后经过GlusterFS Client的计算，并最终经过网络将请求或数据发送到GlusterFS Server上。
vivo的备份模块使用的GlusterFS 文件系统，分别在两个区域的机房中。其中A机房是用于数据库备份和恢复，B机房主要用于异地灾备，增加备份文件的安全性。
A机房的文件系统主要挂载至备份恢复的主控机上，并且A机房文件系统也会挂载到需要物理备份的物理机上。数据库的物理机任何DBA人员均可登录，只要登录该机器上，便可以操作任一备份文件，这对于备份文件是十分危险的；由于A机房是单机房，存在单机房故障的可能，基于以上两点，B机房就应运而生了。
B机房的文件系统只挂载至备份恢复机器的主控机上，并且把A机房的备份文件拷贝至B机房，同时管控备份恢复的主控机权限，便可以确保备份文件系统的安全性。基于此，备份恢复主控机及B机房物理机权限只有2个人有权限访问，从而确保备份文件的安全性。
2.5 Copy 模块
Copy 模块主要用于备份文件的拷贝，让备份文件保留2份副本，防止因A机房宕机，误删等情况下，导致备份文件的缺失。
A机房的文件系统用于数据库直接备份，B机房的文件系统中的数据，是由A机房通过Copy程序拷贝过来，在B机房保留一份副本。由于A机房承接备份和恢复两大功能，而且还要应用于拷贝文件至B机房，还要定时删除过期的备份文件，由此可知A机房的文件系统压力将有多大，这也是直接导致Copy程序效率将有多差，最终结果是B机房的文件要远远落后A机房，导致B机房异地备份名存实亡，Copy模块也变得形同虚设。
2.6 旧备份恢复系统存在问题
1. 效率不足
MySQL 两天才能完成一次全备份，而且恢复实例时间也比较长，不能满足日常恢复实例的时间要求。
MongoDB 大容量数据库比较多，而且逻辑备份已经无法应付现在的场景，超过50%以上的MongoDB集群已无法成功备份。
2. 旧功能不足
旧备份恢复系统目前只有 备份模块、恢复模块、Copy模块，功能单一，已经不能满足互联网领域的快速发展。
备份系统是Python代码完成的，最初开发未考虑高可用，逻辑复杂，维护困难。
3. 文件系统方面
① 文件系统权限控制较弱，不能达到安全要求
-
A机房文件系统会有多处挂载，导致备份文件安全无法得到保障
② 文件系统压力较大，文件系统已经不堪重负
③ 异地灾备形同虚设
受文件系统读写的限制，异地灾备的文件系统存储的都是几天之前的备份文件
三、新备份恢复系统
基于Python开发的旧备份恢复系统存在许多缺点，最后引入Java 开发人员和对象存储，对备份系统进行全方位的改造，经过一系列改进，互联网领域目前的备份系统架构图如下：
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.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.
db.fsyncLock() 锁住整库后，可以直接对MongoDB 文件进行cp、scp或者tar 操作，因此，利用该特性进行物理机备份。
由于需要db.fsyncLock()需要锁整个库，为了不影响部分业务的读写分离要求，因此需要增加一个隐藏节点，为了节省资源，我们把其中3个副本中的一个副本作为隐藏节点，在任何业务需要时，可以直接转变为非隐藏节点提供服务，副本被设置为隐藏节点后，是不能对业务提供服务的，只做备份使用。
增加隐藏节点
增加隐藏节点cfg = rs.conf()cfg.members[2].priority = 0cfg.members[2].hidden = truecfg.members[2].votes = 1rs.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. 定点恢复模块
定点恢复模块主要应用于误删数据后的恢复工作，该系统的架构图如下：
首先，需要与开发人员沟通误删数据时间点，从主库中寻找对应的binlog 位点，或者是gtid信息，并在我们的内部管理系统daas上的【备份管理】中选择出指定的备份文件，并在daas管理系统提数据恢复工单，工单界面图如下：
恢复位置点，我们有三种选择方式，选择无，及时恢复到某个备份文件即可，不再追binlog，gitd位点是用于开启gtid的数据库服务，binlog位点是应对未开启gtid的数据库服务。在审批人（一般是该项目开发的负责人）通过后，定点恢复模块便对恢复机器下发命令，从对象存储获取指定的备份文件，恢复数据，通过start slave until 命令恢复至指定的位置点。
以下是恢复完成后的工单详情，通过访问目标ip和目标端口来查看恢复的数据。
定点恢复受限于物理机磁盘限制，因为要应对各种大小的数据库，我们准备了一个非常大的物理磁盘，不过该磁盘是普通的ssd，因此恢复时间上会比较慢。而且恢复时长也跟数据库的备份文件大小有关，数据库越大，恢复越慢。由于MySQL数据库现在使用了物理备份，恢复单个表只能先全库恢复，再追位点，因此恢复效率比较低。如果是基于Mydumper 逻辑备份的，恢复单个表，会非常快速，因为只需要把恢复的表拷贝出来，即可单独恢复。然而目前却无法实现，在备份效率和定点恢复效率上，我们选择了前者。
定点恢复只需要DBA找到具体的恢复时间点，然后配置恢复页面，系统会自动为我们创建实例，恢复至指定的时间点，从而恢复数据。该操作减少DBA的直接恢复操作，并且以此功能作为一个保底的数据恢复，在定点恢复执行的过程中，如果DBA 有其他方案，可以直接使用另外一套方案来恢复，两个方案同时进行，对恢复数据增加双层保险。
目前误删数据还有许多事情可以去做，使用更多的恢复方案提高恢复效率。
5. 自动化迁移模块
自动迁移模块是基于备份文件实现的，vivo的MySQL组件使用的是物理机混合部署，磁盘使用的是4T的nvme 盘，因此会受到磁盘容量的影响。我们是多实例部署，共享cpu，内存，磁盘空间。随着业务的增长，磁盘使用容量会慢慢的增加，我们目前设定磁盘使用88%时，便自动提单迁移实例。之所以选择磁盘使用率的88%，是因为我们的报警是从90%开始，主要是为了降低磁盘方面的告警。
目标：
-
提高物理机磁盘使用率
-
减少DBA人工迁移的工作量
-
提高迁移效率
-
单个工单形成扩容、主从切换、域名切换、回收的闭环
选择实例的规则：
-
从库优先迁移
-
磁盘使用率10%左右的优先迁移
-
实例资源小于100G的不迁移
迁入物理机选择规则：
获取满足需求的物理机: 满足 【物理机磁盘使用率】+ 【迁移实例磁盘使用量】 小于物理机磁盘使用率80%
流程图如下：
自动化迁移工单图
该功能包含扩容节点、主从切换、迁移域名、回收实例等步骤。如果出现选择的实例不易迁走，可以使用【更改节点结单】或者【回收实例结单】功能完成整个工单的闭环。
目前该项功能已经投入使用，直至目前已经提单259个，提高迁移效率达95%以上。
3.4 新备份恢复系统的不足
1. MongoDB shard 备份缺陷
由于MongoDB shard 引入，MongoDB shard 备份还未有更好的备份方案。目前MongoDB shard 依旧是使用物理备份，但是对数据恢复上还存在不足。在恢复至某一个时间点上，还需要使用oplog单独对每个分片进行恢复，恢复起来步骤复杂。
2. 数据恢复效率不高
数据恢复是在数据被误删的时候发起的操作，虽然使用频率较低，但是该功能却是非常重要的，目前恢复数据是基于全库恢复+binlog重做，恢复效率较低，依旧有很多的恢复方案亟待加入，提高恢复数据的效率，减少因误删数据产生的影响。
四、总结
4.1 安全
旧系统主要是文件系统安全，由于使用的是GlusterFS文件系统，物理机备份主要是挂载到目标机器上，导致登录物理机后，可以不受限制的操作备份文件，非常危险，虽然异地灾备文件系统只挂载至备份控制机，权限控制的比较严格，但是由于拷贝速度的限制，异地的副本已名存实亡。
使用新系统后，备份文件存储于多个机房之中，某个机房全部宕机，也不影响备份文件的读取，因此对备份文件保护得到了加强。同时由于对象存储系统未使用挂载形式，因此，DBA和系统工程师无法下载备份文件，也无法操作备份文件系统，让备份文件更加安全。
4.2 效率
受限于旧文件系统效率写入以及逻辑备份速度，MySQL 备份2天才能完成一轮备份，MongoDB 由于实例太大，受限于mongodbdump 本身的特性，备份时间很长，而且很容易失败。虽然优化后，改成ssd 盘备份，但受限于盘的大小，MongoDB 的备份效率依旧不好。
通过更换文件系统，以及备份策略，极大的提高了备份效率，备份从之前的2天完成备份，提高至10个小时完成备份。
自动化迁移在减少DBA选择实例的同时，也能形成完整的闭环，DBA在操作的时候只需要根据工单的流程即可，极大的提高了工作效率。
4.3功能模块扩展
自从使用Java 语言后，并且有专门的 Java 开发人员的介入，新功能需求得到了实现，经过多轮的优化，目前新备份恢复系统运行非常稳定。基于备份文件，我们扩展了定点恢复模块、自动化迁移方案、以及机器故障自动发起迁移等功能，极大的提高DBA的工作效率，让我们有更多的时间去解决企业的痛点。
END
猜你喜欢
本文分享自微信公众号 - vivo互联网技术（vivoVMIC）。
如有侵权，请联系 [email protected] 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。