国产数据库备份恢复实现

数据库备份恢复是数据库高可用的基本能力，如何通过备份数据快速高效的恢复业务并且满足不同场景下的恢复需求，是各数据库厂商需要关注的要点。本文将介绍几种国产数据库的备份恢复功能，以加深了解。

1、数据库备份恢复方案

数据库备份是生产运维管理中不可或缺的部分，当生产业务数据丢失或者损坏时能够通过备份数据快速恢复数据以恢复业务。通常的数据库备份方案有以下几种：

数据库工具完成备份到本地或NAS文件，再由集中备份设备进行统一备份管理；
数据库备份工具备份数据到远端或云端的存储设备，如COS或OBS，再由集中备份设备进行统一备份管理；
第三方工具代理直接备份数据库到集中备份设备进行管理。

在以上备份方案中，首先要满足备份恢复带宽需求，本地或云端的存储设备能否满足备份及恢复的时效性要求；其次是备份过程的影响，对主库及业务影响、是否支持备库。还有数据恢复的一致性要求，是否支持PITR一致点的恢复，这个是每一种数据库产品自身的能力。最后就是备份恢复任务的管理和监控，备份成功失败、备份超时、备份任务取消等能够通过统一的管理平台进行操作。本文将介绍几种国产数据库的备份恢复功能，以加深了解。

2、国产数据库备份恢复功能

2.1 OceanBase数据库

备份恢复是 OceanBase数据库高可靠的核心组件，通过纯SQL的命令就可以使用完整的备份和恢复功能。OceanBase支持租户级别的物理备份，备份数据包括数据和归档日志：

数据备份包括租户相关的信息以及全部用户表数据，也就是备份时刻的Major SSTable+Minor SSTable，分为全量备份和增量备份。
日志归档是OBServer节点会定期将日志数据归档到指定的备份路径，也就是事务层生成的Clog，包含了SSTable之后修改的数据。

OceanBase数据库支持的备份介质包括OSS、NFS、COS、AWS S3以及兼容S3协议的对象存储（如华为OBS）等备份介质。

OceanBase数据库支持租户级别和表级别的恢复：租户级恢复是基于已有数据的备份重建新租户的过程；表级恢复是从备份数据中将用户指定的表恢复到一个已存在的租户，该功能在V4.2.1版本后才支持。

2.1.1 日志归档

日志归档的工作由日志流的Leader副本负责。按照日志流备份日志，是Log Entry级别的物理备份，默认备份周期是2分钟。每一条归档日志实际上是一个日志集合，包含若干条Log Entry，该条归档日志称之为Log Group。每个Log Entry 都有一个SCN与之关联，Log Group也有一个 SCN，是所有Log Entry中最大的SCN。

1）开启和关闭日志归档

#开启指定租户的归档模式
ALTER SYSTEM ARCHIVELOG TENANT = mysql_tenant;
#关闭集群中指定租户的归档模式
ALTER SYSTEM NOARCHIVELOG TENANT = mysql_tenant;

2）查看归档信息

#查看当前租户归档相关的参数
SELECT * FROM oceanbase.DBA_OB_ARCHIVE_DEST;

2.1.2 数据备份

数据备份的流程均由Root Service节点调度，并按照日志流进行备份。备份数据包括分区的元信息和宏块数据。物理备份是指宏块数据的物理备份，元信息是内存序列化后的值。数据备份优先选择Follower副本进行备份。

1）配置租户备份目标端

#为指定租户配置备份目的端
ALTER SYSTEM SET DATA_BACKUP_DEST= 'data_backup_path' TENANT = mysql_tenant;

2）发起全量备份

#设置备份的并发度
ALTER SYSTEM SET ha_low_thread_score = 10;
#指定租户发起全量数据备份
ALTER SYSTEM BACKUP TENANT = mysql_tenant [PLUS ARCHIVELOG];

2.1.3 数据恢复

OceanBase数据库支持租户级别恢复和表级别恢复，其中租户恢复保证了跨表、跨分区的全局一致性。租户恢复流程如下：

RS根据备份的数据创建需要的日志流。
日志流的Leader调度自己恢复数据和日志，Follower从Leader拉取数据和日志。
RS检测到所有的日志流恢复完成以后，认为租户数据恢复完成。

OceanBase数据库的恢复支持在同集群内恢复，也支持在不同的集群内恢复。

1）租户恢复

#恢复到指定时间戳
ALTER SYSTEM RESTORE dest_tenant_name FROM uri UNTIL TIME='timestamp' WITH 'restore_option' [WITH KEY FROM 'backup_key_path' ENCRYPTED BY 'password'] [DESCRIPTION description];
#恢复到指定SCN
ALTER SYSTEM RESTORE dest_tenant_name FROM uri UNTIL SCN=scn WITH 'restore_option' [WITH KEY FROM 'backup_key_path' ENCRYPTED BY 'password'] [DESCRIPTION description];
#恢复到最新位点
ALTER SYSTEM RESTORE dest_tenant_name FROM uri WITH 'restore_option' [WITH KEY FROM 'backup_key_path' ENCRYPTED BY 'password'] [DESCRIPTION description];

恢复任务完成后，如果是从低版本的备份数据恢复到高版本集群中的场景，还需要对恢复出来的租户进行升级。如果物理恢复后的租户为备租户，后续该租户可作为备租户提供相关服务，也可转为主租户提供服务。

2）表级别恢复

OceanBase数据库的表级恢复功能是通过从备份数据中将用户指定的表恢复到一个已存在的租户中来实现的，并且该已存在的租户与原表所在的租户可以是同一个租户，也可以是同一集群中的不同租户，还可以是不同集群中的租户。表恢复过程中需要使用辅助租户：首先在辅助租户中将数据恢复到指定时间点；再将指定的表从辅助租户跨租户导入到目标租户中；最后清理辅助租户。

ALTER SYSTEM 
RECOVER TABLE infodb.tbl1,infodb.tbl2 
TO TENANT oracle001 
FROM 'file:///data/nfs/backup/data,file:///data/nfs/backup/archive' 
UNTIL TIME='2023-09-30 00:00:00' 
WITH 'pool_list=restore_pool'
REMAP TABLE infodb.tbl1:newtbl 
REMAP TABLEGROUP tg1:newtg1
REMAP TABLESPACE ts1:newts1;

表级别恢复仅支持恢复用户表。另外恢复表时，指定的表名需要与系统实际存储的表名一致。

2.2 TiDB数据库

TiDB数据库支持对集群某个时间点全量数据的备份，也就是快照数据，包含某个物理时间点上集群满足事务一致性的所有数据。同时为了满足PITR的任意时间点的恢复需求，需要开启日志备份，也就是TiKV中的kv变更数据的记录。基于集群的快照数据备份和日志备份数据，可以恢复到集群的任意时间点PITR。

2.2.1 快照备份与恢复

快照备份恢复是由BR工具实现的，具体流程如下：

备份流程
- BR接收备份命令 br backup full。
- BR调度备份数据：创建备份请求，发送给 TiKV 节点，备份请求包含 backup ts、需要备份的 region、备份存储地址
- TiKV接受备份请求，初始化backup worker。
- TiKV备份数据，从Region (only leader)读取backup ts对应的数据，并上传SST文件到备份存储中
- BR从各个TiKV获取备份结果。
- BR备份元信息，并上传到备份存储。
恢复流程
- BR接收恢复命令br restore，获得快照备份数据存储地址、要恢复的database或table
- BR调度恢复数据，根据PD分配的Region结果，发送恢复请求到对应的TiKV节点，恢复请求包含要恢复的备份数据及rewrite规则。
- TiKV接受恢复请求，初始化restore worker。
- TiKV恢复数据，restore worker将处理好的SST文件ingest到RocksDB中
- Report restore result：restore worker 返回恢复结果给BR。
- BR从各个TiKV获取恢复结果，全部备份都恢复成功后，则整个恢复任务成功。

2.2.2 日志备份与PITR恢复

备份流程
- BR接收备份命令br log start，解析获取日志备份任务的checkpoint ts（日志备份起始位置）、备份存储地址。
- TiKV监控日志备份任务的创建与更新。
- TiKV log backup observer持续地备份KV变更日志，读取kv数据变更，然后保存到自定义格式的备份文件中，并定期将日志备份数据和local metadata上传到备份存储中。
- TiDB Coordinator监控日志备份进度，根据各个Region checkpoint ts，计算整个日志备份任务的进度(global checkpoint ts)，然后上报给PD。
- PD持久化日志备份任务状态。可以通过br log status查询。
PITR恢复流程
- BR接收恢复命令br restore point，解析获取全量备份数据地址、日志备份数据地址、恢复到的时间点。
- BR恢复全量备份，进行快照备份数据恢复。
- BR恢复日志备份，读取日志备份数据，创建日志恢复请求，发送到对应的TiKV，日志恢复请求包含要恢复的日志备份数据信息。
- TiKV接受BR的恢复请求，初始化log restore worker。
- TiKV恢复日志备份数据，log restore worker根据恢复集群表的table ID对备份数据的kv进行重写，并将处理好的kv通过raft接口写入store (RocksDB)中。
- BR从各个TiKV获取恢复结果，全部备份数据都恢复成功后，则恢复任务成功。

2.2.3 BR备份恢复使用

TiDB支持将备份数据写到Amazon S3和NFS等存储设备。使用BR命令完成备份恢复功能。

1）对集群进行快照备份

tiup br backup full --pd "${PD_IP}:2379" \
    --backupts '2022-09-08 13:30:00 +08:00' \
    --storage "" \
    --ratelimit 128 \

2）恢复快照备份数据

tiup br restore full --pd "${PD_IP}:2379" \
--storage ""

3）恢复指定库表的数据

tiup br restore table --pd "${PD_IP}:2379" \
--db "test" \
--table "usertable" \
--storage ""

4）开启日志备份

tiup br log start --task-name=pitr --pd "${PD_IP}:2379" \
--storage ''

5）进行PITR恢复

tiup br restore point --pd "${PD_IP}:2379" \
--storage='' \
--full-backup-storage='' \
--restored-ts '2022-05-15 18:00:00+0800'

补充说明：TiDB的备份对集群的性能有一定的影响，如影响IO、事务时延以及QPS。可以通过--ratelimit 参数对备份任务进行限速、配置项 backup.num-threads限制备份任务使用的工作线程数量。

2.3 OpenGauss数据库

OpenGauss数据库支持逻辑备份和物理备份的方式：逻辑备份是将表的数据转储到文件，适用于数据量较小或者数据迁移、表变更等场景；物理备份通过物理文件拷贝的方式，以磁盘块为基本单位进行备份，一般用于全量备份恢复场景。

2.3.1 逻辑备份与恢复

openGauss逻辑备份使用gs_dump工具，可以导出一个数据库或其中的对象（模式、表、视图等）。gs_dump支持将数据库信息导出至纯文本格式的SQL脚本文件或其他归档文件中：

纯文本格式的SQL脚本文件：包含将数据库恢复为其保存时的状态所需的SQL语句。通过gsql运行该SQL脚本文件，可以恢复数据库。
归档格式文件：包含将数据库恢复为其保存时的状态所需的数据，可以是tar格式、目录归档格式或自定义归档格式，该导出结果必须与gs_restore配合使用来恢复数据库。

另外通过gs_dumpall可以导出所有数据库相关信息，包括数据库元数据、表空间等信息以及各数据库的SQL脚本文件。为了保证数据一致性和完整性，gs_dumpall会对需要转储的表设置共享锁，如果无法在指定时间内锁定某张表，备份会失败。

2.3.2 物理备份与恢复

openGauss物理备份有gs_backup、gs_basebackup等工具：gs_backup是导出数据库参数文件及二进制文件，适合数据量小的备份恢复场景；gs_basebackup而是对数据库二进制文件进行全量拷贝，结合PITR恢复场景可恢复全量备份到某一时间点。

1）gs_backup备份

#备份数据库主机
gs_backup -t backup --backup-dir=BACKUPDIR [-h HOSTNAME] [--parameter] [--binary] [--all] [-l LOGFILE]
#恢复数据库主机
gs_backup -t restore --backup-dir=BACKUPDIR [-h HOSTNAME] [--parameter] [--binary] [--all] [-l LOGFILE] [--force]

2）gs_basebackup

gs_basebackup对服务器数据库文件的二进制进行拷贝，其实现原理使用了复制协议。gs_basebackup仅支持主机和备机的全量备份，不支持增量备份。

3）PITR恢复

openGauss的PITR恢复支持恢复到备份归档后的任意时间点。目前只有主节点可以进行PITR恢复，备机需要全量build达成主机一致。在PITR的恢复流程中，需要将归档的WAL日志文件复制到pg_xlog文件中，通过备份数据追加日志的方式恢复到指定时间点。

4）gs_probackup

gs_probackup用于管理openGauss的备份恢复工具，可以对实例进行定期恢复，支持全量、增量和远程备份。

#初始化备份目录
gs_probackup init -B backup_dir
#添加一个新的备份实例
gs_probackup add-instance -B backup_dir -D data_dir --instance instance_name
#创建指定实例的备份
gs_probackup backup -B backup_dir --instance instance_name -b backup_mode
#从指定实例的备份中恢复数据
gs_probackup restore -B backup_dir --instance instance_name -D pgdata-path -i backup_id

2.4 GaussDB数据库

GaussDB提供基于OBS/NAS存储介质的集群级/库表级物理备份能力，并在同构数据库（分片个数相同、大版本号相同）中提供集群级/库表级恢复能力。支持全量备份和增量备份。采用分布式并行技术，并行地对每个数据实例的数据文件进行物理备份恢复，提供了极高的备份恢复性能。在此基础上，还提供备份数据压缩、备份流控、断点续传等高阶功能。

全量备份图所示，会备份全量的数据文件以及截止到barrier lsn的增量日志。在做PITR恢复的时候，基于全量和增量备份集以及归档日志，将实例恢复到任意时间点。

1） Roach备份恢复工具

GaussRoach.py工具是GaussDB提供的用于备份和恢复的实用工具，可对整个数据库中的数据、WAL归档日志和运行日志进行备份。该工具不仅可以备份恢复集群，也可以备份恢复单表；不仅可以备份到物理磁盘，也可以备份到OBS和NAS；不仅可以从集群级备份中恢复集群，也可以从集群级备份中恢复数据库/表。

#备份集群到NAS
python3 GaussRoach.py -t backup --master-port 6000 --media-destination /home/userA/media --media-type NAS --metadata-destination /home/userA/metadata --cluster-unique-id gaussdb_backup
#备份表到NAS
python3 GaussRoach.py -t backup --master-port 6000 --media-destination /home/userA/media --media-type NAS --metadata-destination /home/omm/metadata --cluster-unique-id gaussdb_backup --gbr-table-list /data/table.json
#从NAS恢复集群
python3 GaussRoach.py -t restore --clean --master-port 6000 --media-destination /home/userA/media --media-type NAS --backup-key 20160121_190548 --metadata-destination /home/userA/metadata --cluster-unique-id gaussdb_backup
#从NAS恢复单表
python3 GaussRoach.py -t restore --clean --master-port 6000 --media-destination /home/userA/media --media-type NAS --backup-key 20160121_190548 --metadata-destination /home/userA/metadata --cluster-unique-id gaussdb_backup --restore-new-cluster --gbr-table-list /data/table.json --aux-db-path /data/aux_db --origin-cluster --gbr-owner 'user1' -U user

2.5 GoldenDB分布式数据库

GoldenDB分布式数据库备份包括data数据备份、binlog日志备份、活跃GTID备份、元数据备份和Sequence备份。GoldenDB数据库支持全量和增量备份，数据备份按照库级别完成的。

Data数据文件备份：使用xtrabackup开启备份，将所有备份文件备份在"KaTeX parse error: Expected group after '_' at position 10: DNip_FULL_̲back_start_time.xbstream"文件内；
Binlog备份：将DN节点的binlog备份到指定的目录，用于数据一致性恢复；
活跃事务GTID备份：将集群的GTID列表备份到指定目录，保证全局节点的数据一致性；
集群元数据：备份集群相关的元数据，主要包括有数据字典，用户密码，索引信息；
Sequence信息：备份集群相关的Sequence数据，主要包括有自增列所在表的库名，表名，起始值，步长，最小值，最大值，当前值等属性

1）Data数据备份流程

insight页面创建定时备份任务到backup_restore库，向CM发送dbtool消息
当CM定时器触发时，CM向各节点DBAgent发起备份请求
DBAgent接收到备份请求后，将备份文件保存到指定备份目录
DBAgent备份完成后，将备份完成结果反馈给CM
CM接收到各节点DBAgent的备份结果，汇总后给MDS
MDS接收到备份结果，将消息备份结果发向OMM， OMM入库

2）Data数据恢复流程

获取恢复所需要的文件。
通过全量备份文件（及增量文件）恢复DN。
应用binlog 文件。
回滚恢复时刻的活跃事务。

3）备份恢复影响

GoldenDB数据库支持在备节点备份，备份和恢复过程会对本地磁盘IO有影响，另外在备份过程中会有短暂的flush table with read lock锁。

2.6 总结

对比国产几种数据库，各自在备份恢复功能上已经具备全量备份和数据一致性恢复的能力，如下表所示。

而整个数据库备份恢复的时效性则依赖于数据量、备份存储设备的性能及带宽情况，能否支持高并发高吞吐的能力。尤其是在集中式数据库中，单个库的容量已经超过10T，如何能确保故障时候通过备份数据快速的恢复业务。

参考资料：