国产数据库备份恢复功能对比

本文对比了OceanBase、TiDB、OpenGauss、GaussDB和GoldenDB等国产数据库的备份恢复功能,涵盖了备份方式、工具、恢复机制等方面。

原文标题:国产数据库备份恢复实现

原文作者:牧羊人的方向

冷月清谈:

数据库备份恢复对数据库高可用至关重要。本文介绍了几种国产数据库的备份恢复方案,并分析了各自的优缺点。

OceanBase 数据库支持租户级和表级物理备份恢复,备份目标包括 OSS、NFS、COS 等。其日志归档功能支持 Log Entry 级别的物理备份,数据备份优先选择 Follower 副本进行,以减少对主库的影响。恢复方面,支持租户级恢复和 4.2.1 版本后的表级恢复。

TiDB 数据库支持快照备份和日志备份,可通过 BR 工具实现任意时间点的恢复(PITR)。快照备份包含某个时间点满足事务一致性的所有数据,日志备份记录 TiKV 中的 kv 变更数据。BR 工具调度备份恢复任务,并与 TiKV、PD 协同完成数据备份与恢复。需要注意的是,备份过程会对集群性能有一定影响,可以通过参数进行调控。

OpenGauss 数据库支持逻辑备份和物理备份。逻辑备份使用 gs_dump 工具,将数据导出为 SQL 脚本或归档文件。物理备份包括 gs_backup、gs_basebackup 等工具,分别适用于不同场景。PITR 恢复支持恢复到备份归档后的任意时间点,但仅限主节点。gs_probackup 工具可用于管理备份恢复任务。

GaussDB 数据库提供基于 OBS/NAS 的集群级/库表级物理备份恢复能力,支持全量和增量备份。其 Roach 工具可用于备份恢复集群、单表等,并支持多种存储介质。采用分布式并行技术,具有很高的备份恢复性能。

GoldenDB 分布式数据库备份包括 data 数据备份、binlog 日志备份、活跃 GTID 备份、元数据备份和 Sequence 备份。支持全量和增量备份,数据备份以库为单位。备份恢复过程会对磁盘 IO 产生影响,并在备份过程中会有短暂的 flush table with read lock 锁。

怜星夜思:

1、文章中提到的几种数据库备份恢复方案,哪种方案在恢复效率方面更有优势?为什么?
2、对于数据量很大的数据库,例如超过 10TB,应该如何选择合适的备份恢复策略?
3、未来数据库备份恢复技术的发展趋势是什么?

原文内容

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

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开启备份,将所有备份文件备份在“$DNip_FULL_$back_start_time.xbstream”文件内;

  • Binlog备份:将DN节点的binlog备份到指定的目录,用于数据一致性恢复;

  • 活跃事务GTID备份:将集群的GTID列表备份到指定目录,保证全局节点的数据一致性;

  • 集群元数据:备份集群相关的元数据,主要包括有数据字典,用户密码,索引信息;

  • Sequence信息:备份集群相关的Sequence数据,主要包括有自增列所在表的库名,表名,起始值,步长,最小值,最大值,当前值等属性

1)Data数据备份流程

  1. insight页面创建定时备份任务到backup_restore库,向CM发送dbtool消息

  2. 当CM定时器触发时,CM向各节点DBAgent发起备份请求

  3. DBAgent接收到备份请求后,将备份文件保存到指定备份目录

  4. DBAgent备份完成后,将备份完成结果反馈给CM

  5. CM接收到各节点DBAgent的备份结果,汇总后给MDS

  6. MDS接收到备份结果,将消息备份结果发向OMM, OMM入库

2)Data数据恢复流程
  1. 获取恢复所需要的文件。

  2. 通过全量备份文件(及增量文件)恢复DN。

  3. 应用binlog 文件。

  4. 回滚恢复时刻的活跃事务。

3)备份恢复影响

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

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

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

参考资料:

  1. https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000000818529

  2. https://docs.pingcap.com/zh/tidb/stable/br-snapshot-guide

  3. https://docs-opengauss.osinfra.cn/zh/docs/5.0.0/docs/DatabaseOMGuide/

  4. https://doc.hcs.huawei.com/db/zh-cn/gaussdb/24.1.30/usermanual/gaussdb_01_247.html

  5. https://www.goldendb.com/#/docsIndex/docs/BackupRecovery_BasicPrinciples

回复:对于数据量很大的数据库,例如超过 10TB,应该如何选择合适的备份恢复策略?

10T?这也太大了,我先备份个 10G 的都费劲,哈哈哈~ 我觉得还是得咨询专业的数据库运维人员,听取他们的建议,选择最合适的策略。毕竟数据无价,恢复策略容不得半点马虎。

回复:未来数据库备份恢复技术的发展趋势是什么?

未来?emmm,我预言,以后备份恢复都会自动化、智能化,甚至可以预测数据故障,提前做好备份,就像电影里演的那样,科技感十足! 到时候我们就解放双手了,哈哈哈~

回复:未来数据库备份恢复技术的发展趋势是什么?

除了云原生、自动化这些,我觉得数据安全和隐私保护也越来越重要。备份数据需要加密存储,访问控制也要更加严格。还有就是跨平台、跨云的备份恢复能力,方便用户在不同环境下迁移数据。

回复:对于数据量很大的数据库,例如超过 10TB,应该如何选择合适的备份恢复策略?

10TB 的数据库确实很大,策略选择要慎重。除了增量备份、云存储这些,还可以考虑数据分片备份、多备份点策略等,总之要保证 RTO 和 RPO 指标满足业务需求。另外,定期进行灾难恢复演练也很重要。

回复:对于数据量很大的数据库,例如超过 10TB,应该如何选择合适的备份恢复策略?

这种情况下,增量备份是必须的,不然每次全量备份耗时太长。还要考虑备份存储的性能和带宽,以及并行备份恢复的能力。我觉得可以考虑云端存储方案,比如 OSS、COS 等,利用云平台的资源优势。

回复:文章中提到的几种数据库备份恢复方案,哪种方案在恢复效率方面更有优势?为什么?

我觉得 GaussDB 的方案在恢复效率上可能更有优势。它采用了分布式并行技术,可以并行地对每个数据实例的数据文件进行物理备份恢复,这样应该比其他数据库串行备份恢复快很多。

回复:文章中提到的几种数据库备份恢复方案,哪种方案在恢复效率方面更有优势?为什么?

效率这东西,不好说啊~哈哈哈,就像下载一样,理论速度很快,实际情况还要看网络、资源占用情况。我觉得这几种数据库各有千秋,OceanBase 看着挺专业的,TiDB 社区活跃,OpenGauss 开源,GaussDB 华为的,GoldenDB 又不一样,具体哪个好,还得看实际使用场景。

回复:文章中提到的几种数据库备份恢复方案,哪种方案在恢复效率方面更有优势?为什么?

从文章来看,GaussDB 因为有分布式并行技术加持,理论上恢复效率应该最高。但实际情况还要考虑数据量、网络带宽、硬件性能等诸多因素。没有绝对的“最优”,只有最适合的方案。其他数据库方案如果针对特定场景优化,也可能达到很高的效率。

回复:未来数据库备份恢复技术的发展趋势是什么?

我觉得云原生、自动化、智能化肯定是趋势。备份恢复操作应该会更加简化,用户只需要设置策略,系统就能自动完成。还有就是更细粒度的恢复,比如单表、甚至单行数据的恢复,这样可以减少恢复时间。