Vivo 데이터베이스 백업 및 복구 시스템 진화

작성자: vivo 인터넷 데이터베이스 팀 - Han Chaobing

이 기사에서는 생체 데이터베이스 백업 및 복구 기능의 진화와 백업 파일의 기능 확장을 소개합니다.

I. 개요

인터넷 분야에서 vivo가 소유한 데이터베이스 구성 요소는 MySQL , MongoDB , TiDB 등이며, 그 중 MySQL 클러스터가 대다수를 차지하고 MongoDB 클러스터가 작은 부분을 차지하며 TiDB 클러스터가 더 작은 비율을 차지합니다. 소개의 편의를 위해 이 기사에서는 변환 전의 데이터베이스 백업 및 복구 시스템을 기존 백업 및 복구 시스템이라고 부르고, 변환 후의 데이터베이스 백업 및 복구 시스템을 새로운 백업 및 복구 시스템이라고 부릅니다. 우리는 기존 아키텍처 시스템에서 시작하여 단점을 발견하고 천천히 최적화하여 새로운 시스템 아키텍처를 형성할 것입니다.

2. 기존 백업 및 복구 시스템

이전 백업 복구 시스템 아키텍처 다이어그램

기존 백업 및 복구 시스템은 Python 언어를 기반으로 개발되었으며 분산 파일 시스템 GlusterFS, Python을 개발 언어로 사용하고 작업 예약 모듈 Celery를 사용하여 백업 및 복구 작업을 실행했습니다. 아마도 이전에는 개발 시간이 촉박했기 때문에 Redis 구성 요소의 서비스 가용성 및 고가용성에 대한 작업이 많지 않았습니다. 물리적 시스템 가동 중지 시간이나 네트워크 문제가 발생하면 백업 시스템의 안정성에 직접적인 영향을 미칩니다.

2.1 백업 모듈

백업 모듈은 기존 백업 및 복구 시스템의 주요 기능 서비스로, 매일 데이터베이스 백업을 완료하기 위한 MySQL, TiDB 및 MongoDB 구성 요소의 백업 예약 및 백업 작업에 주로 사용됩니다. 기존 백업 및 복구 시스템은 주로 논리적 백업을 사용하고 5개의 물리적 머신에서만 백업 작업 시작 및 실행을 담당합니다. 인터넷 규모가 크기 때문에 데이터베이스를 완전히 준비하는 데 2일이 걸리므로 성공률은 다음과 같습니다. 백업은 2일 통계와 같습니다. 파일 시스템의 높은 부하, 백업 중 잠금 등으로 인해 백업 예약이 실패할 수도 있으며 결과적으로 전체 물리적 머신의 인스턴스가 백업을 다시 시작할 수 없으며 백업을 계속하려면 수동 유지 관리가 필요합니다. 매우 귀찮습니다.

2.2 구성 요소 백업 소개

MySQL 및 TiDB 백업

[백업 도구]: Mydumper + Xtrabackup(MySQL)

[백업 방법]: 논리적 백업 + 물리적 머신 백업

논리적 백업 Mydumper 도구

Mydumper는 커뮤니티 오픈 소스 논리 백업 도구입니다. 이 도구는 주로 C 언어로 작성되었으며 현재 MySQL, Facebook 및 기타 회사의 직원이 개발 및 유지 관리하고 있습니다.

공식 소개를 참조하면 Mydumper는 주로 다음과 같은 기능을 가지고 있습니다 .

멀티스레드 데이터 내보내기를 더 빠르게 지원합니다.
일관된 백업을 지원합니다.
공간을 절약하기 위해 내보낸 파일 압축을 지원합니다.
다중 스레드 복구를 지원합니다.
데몬 모드, 예약된 스냅샷 및 연속 바이너리 로그 작업을 지원합니다.
지정된 크기에 따라 백업 파일 절단을 지원합니다.
데이터는 테이블 생성 문과 분리됩니다.

Mydumper의 주요 작업 단계 :

메인 스레드는 읽기 잠금이 있는 테이블을 플러시하고 전역 읽기 전용 잠금을 적용하여 DML 문 쓰기를 방지하고 데이터 일관성을 보장합니다 .
현재 시점의 바이너리 로그 파일명과 로그 쓰기 위치를 읽어 메타데이터 파일에 기록하여 복구용으로 활용한다.
일관된 스냅샷으로 트랜잭션 시작, 일관된 읽기 트랜잭션을 시작합니다.
테이블 및 테이블 구조를 내보내려면 n(스레드 수 지정 가능, 기본값은 4) 덤프 스레드를 활성화합니다.
비트랜잭션 테이블을 백업합니다.
메인 스레드는 테이블의 잠금을 해제하며, 비트랜잭션 테이블의 백업이 완료된 후 전역 읽기 전용 잠금이 해제됩니다.
트랜잭션 덤프 innodb 테이블을 기반으로 합니다.
거래가 종료됩니다.

PingCAP은 위의 Mydumper 기능을 기반으로 TiDB의 기능을 최적화했으며, Mydumper는 tidb-enterprise-tools 설치 패키지에 포함되어 있습니다. TiDB의 경우 백업 일관성을 보장하기 위해 FLUSH TABLES WITH READ LOCK을 사용하는 대신 tidb_snapshot 값을 설정하여 데이터 백업 시점을 지정하여 백업 일관성을 보장할 수 있습니다. TiDB의 숨겨진 열 _tidb_rowid를 사용하여 단일 테이블의 데이터 동시 내보내기 성능을 최적화합니다. TiDB는 초기에 공식적으로 Mydumper 백업 도구를 제공했으며 이후에는 BR 물리적 머신 백업 도구를 제공했지만 물리적 머신 백업은 파일 시스템으로 제한되어 있으며 GlusterFS 파일 시스템에서는 Mydumper만 논리적 백업에 사용할 수 있습니다.

Mydumper 백업은 논리적 백업이고 전체 테이블을 읽어야 하므로 백업 효율성이 훨씬 낮아집니다. 파일 시스템이 변경되지 않은 동일한 데이터베이스의 논리적 백업과 물리적 백업을 비교합니다.

이 통계를 보면 논리적 백업 시간이 매우 불안정하다는 것을 알 수 있는데, Mydumper 백업의 최단 시간은 6.5시간, 최장 시간은 23시간인 반면, 물리적 머신 백업 시간은 기본적으로 약 7시간을 유지하고 있습니다.

물리적 머신 백업 Xtrabackup 도구

Xtrabackup은 MySQL 데이터베이스의 물리적 핫 백업을 위해 Percona 팀에서 개발한 오픈 소스 백업 도구로, 빠른 백업 속도, 백업 데이터 압축 지원, 백업 데이터 자동 확인, 스트리밍 출력 지원, 거의 영향을 미치지 않는다는 특징을 가지고 있습니다. 백업 프로세스 중 비즈니스 관련 MySQL 백업 도구는 현재 다양한 클라우드 공급업체에서 일반적으로 사용됩니다.

물리적 머신 백업은 압축 및 패키징을 사용하지 않기 때문에 백업되는 파일은 테이블 크기로 제한됩니다. 특히 큰 테이블을 백업하는 경우 파일 시스템은 항상 고르지 않게 분산됩니다. 대부분의 디스크의 경우 80% 시간, 일부 그러나 디스크의 사용 용량이 95%를 초과하므로 파일 시스템에 자주 로그인하고 백업 파일을 삭제해야 알람이 제거됩니다. 또한 물리적 백업 구성 비율도 적고 백업 비율도 높지 않습니다. 이후 일부 최적화(패키징 및 파일 분할 기능 추가)가 이루어졌지만 고르지 않은 디스크 배포 문제는 해결되었습니다. 그러나 백업 성공률은 크게 향상되지 않습니다.

몽고DB 백업

[백업 도구]: mongodbdump

[백업 방법]: 논리적 백업

[백업 시간]: 하루 종일 기간

mongodbdump는 MongoDB에서 공식적으로 제공하는 백업 프로그램으로 100G 미만의 백업도 쉽게 처리할 수 있지만, 100G보다 큰 인스턴스도 백업할 수 있지만 백업 시간이 길어집니다. Vivo는 현재 1T보다 큰 인스턴스가 수십 개 있는데, 백업이 어렵고 백업 성공률도 매우 낮은 것은 이해할 수 있습니다. 일부 MongoDB 인스턴스는 너무 커서 이것이 결코 성공하지 못합니다. 이틀 동안의 백업 성공률은 기본적으로 20% 내외이고, 일주일 동안의 성공률을 계산해도 40%에 도달하지 못합니다. 1T보다 큰 MongoDB 인스턴스의 경우 파일 시스템이 너무 느리기 때문에 항상 중간에 백업이 실패합니다. , 많은 최적화 후에도. , 백업 디스크를 로컬 디스크에 배치한 다음 파일 시스템에 복사하더라도 백업 성공률이 향상되었지만 여전히 성공률이 매우 낮으며 빈번한 수동 유지 관리가 필요합니다.

2.3 복구 모듈

복구 모듈 도 Python을 기반으로 개발되었습니다. Celery 모듈은 복구 전략을 예약하고 구성된 데이터베이스 백업 방법에 따라 해당 논리적 및 물리적 머신 복구를 선택합니다.

논리적 복구 는 백업 파일을 직접 이용하여 대상 데이터베이스를 복원하는 방법인데 논리적 복구 속도가 매우 느리다.. 예전에 T 데이터베이스 복구를 해본 적이 있는데 복구에 하루 정도 걸렸다. 하지만 논리적 백업도 장점이 있는데, 단일 테이블을 복원할 때 해당 테이블의 파일 시스템을 직접 복사한 후 myloader 프로그램을 이용하면 직접 복원할 수 있고, 단일 테이블을 매우 빠르게 복원할 수 있는데, 이는 단일 테이블을 복원하는 것보다 훨씬 빠르다. 물리적 머신의 단일 테이블. . 그러나 여기서 복구하려면 수동 작업이 필요하며 코드에서는 이 기능을 구현하지 않습니다. .

물리적 머신 복구 는 파일 시스템 마운트 방법을 직접 사용하고, 파일 시스템을 대상 머신에 직접 마운트한 후, 백업 파일을 대상 머신에 복사하여 데이터를 복원하는 방법으로, 기능이 비교적 간단합니다. 회복 속도가 상대적으로 느리므로 더 빠르게 하세요.

恢复模块仅用于增加从库实例和延迟从库，未做到任一时间点的恢复，功能相对单一。

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 = 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. 定点恢复模块

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

首先，需要与开发人员沟通误删数据时间点，从主库中寻找对应的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 데이터베이스 백업 및 복구 시스템 진화

추천