详解OceanBase数据库备份恢复保障数据安全17认证网

正规官方授权
更专业・更权威

详解OceanBase数据库备份恢复保障数据安全

OceanBase数据库的备份、恢复、保障数据安全

数据库在现代IT系统中的重要性不言而喻,而数据的可用性和可靠性也是数据库的重要特性之一。备份恢复作为商业数据库必不可少的组件之一,为数据的可用性和可靠性提供了最后一层屏障。在数据库由于种种原因导致不可用时,如果有数据备份,那么就可以通过恢复功能将数据库恢复到故障之前的状态,继续为应用提供服务。数据库按备份形式来分,主要分为逻辑备份和物理备份。物理备份是把数据库中的物理文件(例如:数据文件、日志文件等)转储到另外的设备上。一旦数据库发生故障,可以利用这些物理备份文件进行还原。逻辑备份是利用导出工具将数据库中的对象(例如:模式、数据等)在逻辑上以特定的格式导出到存储设备上,我们可以利用导入工具把逻辑备份出来的文件导入到数据库。从备份时数据库的运行状态来看,备份恢复主要分为冷备、温备和热备。冷备时数据库不提供在线的读写服务,用户将机器上的数据库软件所包括的控制文件、配置文件以及数据/日志文件进行归档迁移到目标机器上并重新启动即可。温备时数据库仅提供在线读服务,用户仅需要考虑冷备操作对于在线读业务的影响。热备时数据库提供在线读写服务,用户不仅要考虑数据的一致性问题,还要考虑备份工作对于在线业务的影响。

机器信息

机器类型 主机配置 备注
OS Centos 7.4
中控机 /OBD CPU:8C 内存:16G
目标机器 /OBserver CPU:8C 内存:32G
系统盘 / dev/vda 100G LVS分区、文件系统:EXT4
数据盘 /data dev/vdb 200G GPT分区、文件系统:xfs
事务日志盘 /redo dev/vdc 100G GPT分区、文件系统:xfs

image-20211231154309608机器划分

角色 机器IP 备注
OBD 172.20.2.131 中控机
OBserver 172.20.2.120 {2881,2882}, {3881,3882} zone1
172.20.2.121 {2881,2882}, {3881,3882} zone2
172.20.2.122 {2881,2882}, {3881,3882} zone3
NFS客户端 172.20.2.120
172.20.2.121
172.20.2.122
NFS服务端 172.20.2.131

物理备份

OceanBase 数据库支持集群级别的物理备份。物理备份由基线数据日志归档数据两种数据组成,因此物理备份由日志归档和数据备份两个功能组合而成:

  • 日志归档指的是日志数据的自动归档功能,OBServer 会定期自动将日志数据归档到指定的备份路径。
  • 数据备份指的是备份基线数据的功能,该功能分为全量备份增量备份两种:
  • 全量备份是指备份所有的需要基线的宏块。
  • 增量备份是指备份上一次备份以后新增和修改过的宏块。

img

物理备份架构

备份集群以后,需要先用 SQL 发起日志归档,等日志归档发起完成启动阶段以后,才可以发起基线备份

日志归档是定期备份到备份目的端的,只需要发起一次 alter system archivelog命令,日志备份就会在后台持续进行。日志归档是由每个 PG(PartitionGroup)的 leader 负责定期将该 PG 的日志归档到备份介质指定的路径,RS(RootService)负责定期统计日志归档的进度,并更新到内部表。

数据备份是需要手工触发的,比较常见的场景是周六触发一次全备,周二周四触发一次增量备份。当用户发起数据备份请求时,这个请求会首先被转发到 RS 所在的节点上;RS 会根据当前的租户和租户包含的 PG 生成备份数据的任务,然后把备份任务分发到 OBServer 上并行的执行备份任务;OBServer 负责备份 PG 的元信息和宏块到指定的备份目录,宏观是按照 PG 为单位管理的。

以下是备份功能在备份目的地创建的目录结构以及每个目录下保存的文件类型。

backup/ # 备份的根目录
└── ob1 # cluster_name
  └── 1 # cluster_id
      └── incarnation_1 #分身id
          ├── 1001 # 租户id
          │   ├── clog # clog的根目录
          │   │   ├── 1 # clog备份的round id
          │   │   │   ├── data # 日志的数据目录
          │   │   │   └── index # 日志的索引目录
          │   │   └── tenant_clog_backup_info # 日志备份的元信息,按照round id分段记录
          │   └── data # 数据的根目录
          │       ├── backup_set_1 # 全量备份的目录
          │       │   ├── backup_1 # 差异备份的目录,第一个差异备份目录是全量的meta    
          │       │   ├── backup_2 # 差异备份的目录。第二个差异备份的目录,meta也是全量备份的。
          │       │   ├── backup_set_info # 记录了backup_set目录内的多次差异备份的信息
          │       │   └── data #宏块数据的目录,包含了所有的全量和差异的宏块
          │       └── tenant_data_backup_info # 记录了租户全部的数据备份信息
          ├── clog_info # server启动日志备份的信息
          │   └── 1_100.88.110.158_12533 # 一个server一个启动日志备份信息
          ├── cluster_clog_backup_info # 集群级别的日志备份信息
          ├── cluster_data_backup_info # 集群级别的数据备份信息
          ├── tenant_info # 租户的信息
          └── tenant_name_info #租户name和id的影射关系

备份管理

OceanBase 数据库的数据备份是用 BackupSet 来管理,一次数据备份会生成一个对应的 backup_set_id,这个 ID 在集群级别是全局唯一的。

  • 对于全量备份来说,会建立一个独立的元信息目录和一个宏块的目录
  • 对于增量备份来说,会建立一个独立的元信息目录,但是会重用对应全量备份的宏块目录
  • OceanBase 数据库的增量备份包含了完整的元信息,只重用的宏块数据,不会影响恢复的性能。

Archive Log Round

OceanBase 数据库的日志归档是连续备份的,不受 Backup Set 的管理。每次执行 ALTER SYSTEM ARCHIVELOG 发起日志归档的时候,会将 Archive Log Round 加 1 。 一个 Archive Log Round 表示一个完整连续的日志备份。

日志归档没有单独的备份管理命令,每次删除数据备份的 Backup Set 的时候,会自动将不再需要的日志归档文件删除。如果一个 Archive Log Round 比现存的所有 Backup Set 都旧,那么整个 Archive Log Round 都会被删除。

恢复支持租户级别的恢复

OceanBase 数据库支持租户级别的恢复,恢复是基于已有数据的备份重建新租户的过程。只需要一个 alter system restore tenant 命令,就可以完成整个恢复过程。

恢复过程包括租户系统表和用户表的 Restore 和 Recover 过程。

  • Restore :将恢复需要的基线数据恢复到目标租户的 OBServer
  • Recover :将基线对应的日志恢复到对应 OBServer。

img

一、配置NFS介质

1、NFS 服务端配置

安装软件,通过 YUM 包管理器安装 NFS
[root@CAIP131 ~]# yum install -y nfs-utils

image-20220310142636389

创建nfs备份目录

[root@CAIP131 /]# mkdir -p /nfs/ob_back

设置 Exports
编辑配置文件

[root@CAIP131 ob_back]# vim /etc/exports
/nfs/ob_back/ 172.20.2.1/24(rw,sync,all_squash)

172.20.2.1/24: 表示允许访问的网段

配置权限

为 nfsnobody 赋权,确保 nfsnobody 有权限访问 exports 中指定的目录

chown nfsnobody:nfsnobody -R /nfs/ob_back

配置 NFS 参数
编辑配置文件
[root@CAIP131 ~]# vim /etc/sysconfig/nfs
RPCNFSDCOUNT=8
RPCNFSDARGS="-N 2 -N 3 -U"
NFSD_V4_GRACE=90
NFSD_V4_LEASE=90

 

重新启动 NFS 服务
systemctl restart nfs-config && systemctl restart nfs-server

 

*设置 Slot Table**

编辑 /etc/sysctl.conf 文件并添加以下信息

[root@CAIP131 ~]# vim /etc/sysctl.conf 
sunrpc.tcp_max_slot_table_entries=128

 

2、NFS 客户端配置

在所有的OBServer 节点上配置

yum安装软件
[root@CAIP120 ~]# yum install -y  nfs-utils

 

设置 Slot Table
vim /etc/sysctl.conf
sunrpc.tcp_max_slot_table_entries=128

 

挂载 NFS
[root@CAIP120 mount -tnfs4 -o rw,timeo=30,wsize=1048576,rsize=1048576,namlen=512,sync,lookupcache=positive 172.20.2.131:/nfs/ob_back /nfs/ob_back

 

验证NFS的性能
[root@CAIP120 fio -filename=/nfs/ob_back/fio_test -direct=1  -rw=randwrite -bs=2048K -size=10M  -runtime=300 -group_reporting -name=mytest  -ioengine=libaio -numjobs=1 -iodepth=64 -iodepth_batch=8 -iodepth_low=8 -iodepth_batch_complete=8

验证报错未安装fio

image-20220310145749340

官网下载地址http://freshmeat.sourceforge.net/projects/fio/

[root@CAIP120 opt]# cd fio-2.1.10/
[root@CAIP120 fio-2.1.10]# ./configure

 

[root@CAIP120 fio-2.1.10]# make

 

[root@CAIP120 fio-2.1.10]# make install

再次验证NFS的性能
[root@CAIP120 fio -filename=/data/nfs/fio_test -direct=1  -rw=randwrite -bs=2048K -size=100M  -runtime=300 -group_reporting -name=mytest  -ioengine=libaio -numjobs=1 -iodepth=64 -iodepth_batch=8 -iodepth_low=8 -iodepth_batch_complete=8

image-20220310151250059

验证正常未报错

二、备份数据

1、通过命令行进行全量备份

1. 1.使用** root用户登录数据库的sys租户
[root@CAIP131 ~]# obclient -h 172.20.2.120 -uroot@sys -P2881 -A -c

1.2. 配置备份目的地址端

 

[root@CAIP131 ~]# cd /nfs/ob_back/
MySQL [(none)]> use sixlens;
MySQL [sixlens]> ALTER SYSTEM SET backup_dest='file:///nfs/ob_back/';

 

使用 NFS 作为备份目的地时,必须保证所有 OBServer 都挂载了同一个服务器的 NFS。同时,为保证备份的顺利进行,务必使用本文档中推荐的参数挂载 NFS。

1.3.配置备份模式,并开启归档日志压缩功能。
备份模式

目前支持 Optional 模式和 Mandatory 模式,默认为 Optional 模式。

  • Optional 模式:表示以用户业务优先。在该模式下,当备份(日志归档)来不及的情况下,日志可能来不及备份就回收了,可能会发生备份断流。
  • Mandatory 模式:表示以备份优先。在该模式下如果备份跟不上业务数据的写入,可能会导致无法写入。
日志压缩

目前支持的压缩算法有:zstd_1.3.8 和 lz4_1.0,默认使用压缩算法 lz4_1.0

详细配置
  • Optional 模式备份,并开启归档日志压缩功能的示例如下:
MySQL [sixlens]> ALTER SYSTEM SET backup_log_archive_option = 'optional compression= enable';

 

  • Mandatory 模式根据业务需要动态修改备份模式和压缩算法,默认使用压缩算法 lz4_1.0
MySQL [oceanbase]> ALTER SYSTEM SET backup_log_archive_option='mandatory compression= zstd_1.3.8';
MySQL [sixlens]> ALTER SYSTEM SET backup_log_archive_option='mandatory compression= lz4_1.0';

 

关闭日志归档压缩
  • 备份模式为 Optional 模式的场景关闭日志归档压缩
MySQL [oceanbase]> ALTER SYSTEM SET backup_log_archive_option = 'compression= disable'; 
#或者#
MySQL [oceanbase]> ALTER SYSTEM SET backup_log_archive_option = 'mandatory compression= disable';
  • image-20220310153649196

  • 备份模式为 Mandatory 模式的场景关闭日志归档压缩
ALTER SYSTEM SET backup_log_archive_option = 'mandatory compression= disable';

1.4. 启动日志备份

为了减少日志备份发起的耗时,建议在开启日志备份前进行一次转储,待转储完成后再备份。这是因为日志备份的起始位点是最近一次转储位点,转储以后可以减少日志备份启动的时间。

MySQL [sixlens]> ALTER SYSTEM ARCHIVELOG;

启动成功后,OceanBase 数据库会自动将集群产生的事务日志定期备份到之前指定的备份目的地。

1.5. 确认日志备份任务是否已开始
MySQL [oceanbase]> SELECT * FROM CDB_OB_BACKUP_ARCHIVELOG_SUMMARY;
-- 查看日志的备份进度
MySQL [oceanbase]> SELECT * FROM CDB_OB_BACKUP_ARCHIVELOG;

当 STATUS为 DOING时,表示日志备份任务已开始。

1.6. 在执行数据备份前,需要对集群发起一轮合并,并等待合并完成。
MySQL [oceanbase]> ALTER SYSTEM MAJOR FREEZE;
MySQL [oceanbase]> SELECT * FROM oceanbase.__all_zone WHERE name='merge_status';

 

当 info 为 IDLE 时,则表示合并结束。

2、发起全量备份

2.1. 设置备份的密码(根据需要可选)
MySQL [oceanbase]> SET ENCRYPTION ON IDENTIFIED BY 'password' ONLY;

2.2. 发起数据备份
ALTER SYSTEM BACKUP DATABASE;

报错,提示日志归档未启用

日志归档启用就好了

2.3. 查看备份任务的状态和详细信息
-- 查看正在备份的任务
SELECT * FROM CDB_OB_BACKUP_PROGRESS; 

-- 查看备份任务的历史
SELECT * FROM CDB_OB_BACKUP_SET_DETAILS;

3、增量备份

增量备份是从上一个全量备份开始,备份所有修改过的宏块。在执行增量备份前,请确保已经有全量备份存在。

  1. 使用 root 用户登录数据库的 sys 租户。
  2. 执行以下语句,启动增量备份。
-- 启动增量备份
ALTER SYSTEM BACKUP INCREMENTAL DATABASE;

4、通过视图查看数据备份进度以及备份任务历史

使用 root 用户登录数据库的 sys 租户。

进入 oceanbase 数据库。

obclient> USE oceanbase;

进行以下操作:

  • 查看备份进度
    obclient> SELECT * FROM CDB_OB_BACKUP_PROGRESS;
    
  • 查看备份历史
    obclient> SELECT * FROM CDB_OB_BACKUP_SET_DETAILS;
    

5、通过视图查看日志的备份进度

使用 root 用户登录数据库的 sys 租户。

进入 oceanbase 数据库。

obclient> use oceanbase;

执行以下语句,查看日志的备份进度。

obclient> SELECT * FROM CDB_OB_BACKUP_ARCHIVELOG;

三、停止备份

使用 root 用户登录数据库的 sys 租户

终止正在运行的数据备份任务
ALTER SYSTEM CANCEL BACKUP;
终止正在运行的日志备份任务
ALTER SYSTEM NOARCHIVELOG;

四、备份数据清理

  • 由于日志归档数据的删除依赖数据的备份,在清理日志归档数据前,请确认已存在数据备份文件,如果没有数据备份文件,则无法清理日志归档数据。
  • 自动清理仅支持删除配置项 backup_dest 中设置的备份目的端的数据,对于更换备份目的端的场景,需要手动清理过期数据。
  • 自动清理会保留至少一份有效的备份数据,如果唯一的一份有效数据已过期,则这份有效数据不能被自动清理。

1、自动清理备份数据

通过 **backup_dest_option** 配置项开启自动清理功能

执行backup_dest_option 配置项设置备份数据的过期时间和清理策略。

示例:开启自动清理功能,并自动清理 7 天之前的数据
ALTER SYSTEM SET backup_dest_option='log_archive_checkpoint_interval=2m&recovery_window=7d&auto_delete_obsolete_backup=true&log_archive_piece_switch_interval=1d';
  • log_archive_checkpoint_interval: 用于控制冷分区(冷分区没有日志写入) Checkpoint 任务的生成间隔,以推进其归档进度。
  • 如果 backup_dest_option 和 log_archive_checkpoint_interval 均未设置,则使用默认值 120s。建议使用 backup_dest_option 配置项设置。
  • 如果 backup_dest_option 和 backup_recovery_window 均未设置,则使用默认值 0,表示备份数据不过期。建议使用 backup_dest_option 配置项来来控制备份数据的保留时间。
  • auto_delete_obsolete_backup :用于控制是否自动删除过期的备份数据
  • 如果 backup_dest_option 和 auto_delete_expired_backup 均未设置,则系统会使用默认值 false,表示不自动删除过期的备份数据,此处需要将 auto_delete_obsolete_backup 设置为 true。建议使用 backup_dest_option 配置项来配置是否自动删除过期的备份数据。
  • log_archive_piece_switch_interval :用于控制自动按照时间段来切日志文件的目录,默认值为 0,表示不切分 Piece, 有效范围为 [1d, 7d]

2、配置项开启自动清理功能

集群级别配置项 auto_delete_expired_backup 也可以用来开启自动清理功能。在日常使用中,建议您使用 backup_dest_option 配置项来开启自动清理功能。

  1. 使用 root 用户登录数据库的 sys 租户。
  2. 根据以下命令,通过 backup_recovery_window 配置项设置备份数据的过期时间。
-- 设置备份数据的过期时间
ALTER SYSTEM SET backup_recovery_window = <过期时间>;

backup_recovery_window: 表示成功备份的数据可以提供恢复的时间窗口,默认值为 0,表示永久保留;建议设置为 '7d',表示备份数据保留一周后过期。

示例
  • 设置7d 自动清理备份的数据
ALTER SYSTEM SET backup_recovery_window = '7d';
  • 配置项开启备份数据的自动清理功能
ALTER SYSTEM SET auto_delete_expired_backup = 'True';

如果出现了 9044 的报错,则表示数据清理任务已开始,不允许再次发起清理任务。

3、手动清理备份数据

手动清理方式主要通过 ALTER SYSTEM 命令删除指定的 backup_set_idbackup_piece_idbackup_round_id 或者过期的数据。

清理前准备

手动清理已经过期的备份数据前,需要先配置备份数据的过期时间和清理策略,即配置 backup_dest_option 配置项中的 recovery_window 和 auto_delete_obsolete_backup

ALTER SYSTEM SET backup_dest_option='log_archive_checkpoint_interval=5s&recovery_window=7d&auto_delete_obsolete_backup=false&log_archive_piece_switch_interval=1d';

如果 backup_dest_option 和 log_archive_checkpoint_interval 均未设置,则使用默认值 120s。建议使用 backup_dest_option 配置项来设置。

auto_delete_obsolete_backup 用于控制是否自动删除过期的备份数据。

如果不通过 backup_dest_option 配置项设置,则默认使用集群级别的配置项 auto_delete_expired_backup 的值。如果 backup_dest_option 和 auto_delete_expired_backup 均未设置,则使用默认值 false,表示不自动删除过期的备份数据,此处需要将 auto_delete_obsolete_backup 设置为 false。建议使用 backup_dest_option 配置项来配置是否自动删除过期的备份数据。

 4、清理指定备份数据

使用 root 用户登录数据库的 sys 租户后
获取待删除的备份数据的 ID 值

分别查询视图 CDB_OB_BACKUP_SET_DETAILS 和 CDB_OB_BACKUP_PIECE_FILES,找到待删除的备份数据的 backup_set_idpiece_id 和 round_id

  • CDB_OB_BACKUP_SET_DETAILS 视图获取backup_set_id
select INCARNATION,TENANT_ID,BS_KEY,BACKUP_TYPE,COMPLETION_TIME,ELAPSED_SECONDES,STATUS,OUTPUT_BYTES,OUTPUT_RATE_BYTES,KEEP_UNTIL 
from CDB_OB_BACKUP_SET_DETAILS;
  • CDB_OB_BACKUP_PIECE_FILES 视图获取round_id 和 backup_piece_id
select INCARNATION,TENANT_ID,ROUND_ID,BACKUP_PIECE_ID,STATUS,FILE_STATUS from CDB_OB_BACKUP_PIECE_FILES\G

根据清理场景,选择合适的命令,清理备份数据。

  • 清理指定 backup_set_id 的数据
obclient> ALTER SYSTEM DELETE BACKUPSET backup_set_id;

表示删除 backup_set_id 为 1 的备份数据。

obclient> ALTER SYSTEM DELETE BACKUPSET 1;

清理指定 piece_id 的归档数据

obclient> ALTER SYSTEM DELETE BACKUPPIECE piece_id;

清理指定 round_id 的日志备份的 Round 中的所有数据

obclient> ALTER SYSTEM DELETE BACKUPROUND round_id;

5、清理过期的备份数据

  1. 使用 root 用户登录数据库的 sys 租户。
  2. 执行以下命令,立即清理过期的备份数据。
-- 立即清理过期的备份数据
ALTER SYSTEM DELETE OBSOLETE BACKUP;
  • DELETE OBSOLETE 命令仅支持删除过期的备份数据,且过期数据所在的路径需要与配置项 backup_dest 的设置相同。
  • DELETE OBSOLETE 命令不支持删除备份的备份数据。
  • 如果 backup_copies 的个数未达到 backup_dest_option 配置中 backup_copies 配置项设置的个数,则不能清理数据。

五、恢复全量数据

通过命令进行物理恢复,目前 OceanBase 数据库支持租户级别的基于时间点的全量恢复。

流程

恢复会先根据用户输入的命令,从备份的目的地将全量备份恢复回来。之后,再将增量备份恢复到全量备份上面。最后,应用备份出去的事务日志。

1.通过命令进行恢复

使用 root 用户登录数据库的 sys 租户

2.(可选)停止日志备份

ALTER SYSTEM NOARCHIVELOG;

3.创建资源单元 (Resource Unit)

CREATE RESOURCE UNIT S1 max_cpu=2, min_cpu=2, max_memory='2G', min_memory='2G',max_iops=1000, min_iops=1000, max_session_num=10000, max_disk_size='20G';

4. 创建 Resource Pool(资源池)

CREATE RESOURCE POOL restore_pool unit = 'S1', unit_num = 1, zone_list = ('zone1','zone2','zone3');

5. (可选)设置加密信息

如果未加密或恢复时可以访问原来的 KMS,则跳过本步骤。

SET @kms_encrypt_info = '<加密string>';

其中,<加密string> 为 EXTERNAL_KMS_INFO 的值,EXTERNAL_KMS_INFO 为租户级配置项

6. 打开恢复配置

检查restore_concurrency的值是否为0,若为0,执行下面命令配置
show parameters like 'restore_concurrency'\G
ALTER SYSTEM SET restore_concurrency = 50;

7. (可选)修改恢复的等待时间

默认恢复等待时间 _restore_idle_time 为 1 分钟,整个恢复期间会有 3 次等待,即 3 分钟的等待时间。

show parameters where name = '_restore_idle_time'\G
ALTER SYSTEM SET _restore_idle_time = '10s';

8. 根据现场需要,设置恢复的密码。

只有在备份时添加了密码的场景下才需要设置恢复的密码。同时如果全量备份+增量备份设置的密码不一样,则需要输入多个密码,密码之间使用逗号分隔。

SET DECRYPTION IDENTIFIED BY 'password';
-- 多个密码的场景
SET DECRYPTION IDENTIFIED BY 'password1','password2';

9. 执行恢复任务

用法
ALTER SYSTEM RESTORE test_tenant_restore FROM test_test_tenant at 'uri' UNTIL 'timestamp'

部分参数说明如下表所示。

ALTER SYSTEM RESTORE restored_trade FROM trade at 'file:///nfs/ob_back/' until '2021-12-22 09:33:07.901747' with 'backup_cluster_name=ob20daily.backup&backup_cluster_id=1&pool_list=restore_pool;

10. 查看恢复进度

查看系统表 Root Table
obclient> SELECT svr_ip,role, is_restore, COUNT(*) FROM __all_root_table AS a, (SELECT value FROM __all_restore_info WHERE name='tenant_id') AS b WHERE a.tenant_id=b.value GROUP BY role, is_restore, svr_ip ORDER BY svr_ip, is_restore;

其中,is_restore 的取值含义如下:

  • 0:表示正常副本
  • 1:表示逻辑恢复的副本
  • 2:表示物理恢复需要恢复基线的副本
  • 3:表示物理恢复需要恢复转储的副本
  • 4:物理恢复需要恢复 clog 的副本
  • 5:物理恢复需要转储的副本
  • 6:物理恢复等待所有副本转储完成的副本
  • 7:物理恢复设置 member list 的副本

role 的取值含义如下:

  • 1:表示 Leader
  • 2:表示 Follower
  • 3:表示恢复中的 Leader
查看用户表 Meta Table
obclient> SELECT svr_ip,role, is_restore, COUNT(*) FROM __all_virtual_meta_table AS a, (SELECT value FROM __all_restore_info WHERE name='test_tenant') AS b WHERE a.tenant_id=b.value GROUP BY role, is_restore, svr_ip ORDER BY svr_ip, is_restore;

或者

obclient> SELECT svr_ip ,is_restore, COUNT(*) FROM __all_virtual_partition_store_info WHERE tenant_id>1002 group by svr_ip,is_restore order by svr_ip, is_restore;

11. 查看恢复结果

obclient> SELECT * FROM __all_restore_info;
obclient> SELECT * FROM __all_restore_history;

查看全量恢复进度和结果

执行全量恢复后,可以通过数据库表来查看恢复进度和结果。

通过数据库表查看恢复进度和结果

  1. 使用 root 用户登录数据库的 sys 租户。
  2. 进入 oceanbase 数据库。
    obclient> USE oceanbase;
    
  3. 执行以下命令,查看恢复进度。
    • 查看系统表的恢复进度
      obclient> SELECT svr_ip,role, is_restore, COUNT(*) FROM __all_root_table as a, (SELECT value FROM __all_restore_info WHERE name='test_tenant') AS b WHERE a.tenant_id=b.value GROUP BY role, is_restore, svr_ip ORDER BY svr_ip, is_restore;
      
    • 查看用户表的恢复进度
      obclient> SELECT svr_ip,role, is_restore, COUNT(*) FROM __all_virtual_meta_table AS a, (SELECT value FROM __all_restore_info WHERE name='test_tenant') AS b WHERE a.tenant_id=b.value GROUP BY role, is_restore, svr_ip ORDER BY svr_ip, is_restore;
      

      或者

      obclient> SELECT svr_ip, is_restore, COUNT(*) FROM __all_virtual_partition_store_info WHERE tenant_id=test_tenant GROUP BY svr_ip,is_restore ORDER BY svr_ip, is_restore;
      

      其中: * is_restore 列显示了一个分区在恢复中所处的状态,当该列值为 0时表示这个分区的数据已经完成了恢复。

      • role 列表示被恢复的副本的角色:
      • 1:表示 Leader
      • 2:表示 Follower
      • 3:表示恢复中的 Leader
  4. 待恢复完成后,您可以执行以下语句,查看集群的恢复任务结果和恢复历史:
    • 查看恢复任务结果
      obclient> SELECT * FROM __all_restore_info;
      
    • 查看恢复历史
      obclient> SELECT * FROM __all_restore_history;

      想了解更多干货,可通过下方扫码关注

      可扫码添加上智启元官方客服微信👇

未经允许不得转载:17认证网 » 详解OceanBase数据库备份恢复保障数据安全
分享到:0

评论已关闭。

400-663-6632
咨询老师
咨询老师
咨询老师