物理备份与恢复概述

备份恢复是 OceanBase 数据库高可用特性的核心组件，主要用于保障数据的安全，包括预防存储介质损坏和用户的错误操作等。如果存储介质损坏或者用户误操作而导致了数据丢失，可以通过恢复的方式恢复用户的数据。

概述

备份恢复是 OceanBase 数据库高可用特性的核心组件，主要用于保障数据的安全，包括预防存储介质损坏和用户的错误操作等。如果存储介质损坏或者用户误操作而导致了数据丢失，可以通过恢复的方式恢复用户的数据。

目前 OceanBase 数据库支持 OSS 和 NFS 两种备份介质，提供了备份、恢复、管理三大功能。

OceanBase 数据库支持集群级别的物理备份。集群的物理备份指的是该集群中除 sys 租户以外的其他所有租户的物理备份。物理备份由基线数据、日志归档数据两种数据组成，因此物理备份由日志归档和数据备份两个功能组合而成。

• 日志归档是指日志数据的自动归档功能，OBServer 会定期将日志数据归档到指定的备份路径。这个动作是全自动的，不需要外部定期触发。

  日志定期归档时间的计算公式如下：

  日志的定期归档时间 = checkpoint_interval /2

  其中，checkpoint_interval 的值可由用户自行配置，详细配置操作请参见 配置备份参数。

• 数据备份指的是备份数据的功能，该功能分为全量备份和增量备份两种：

  • 全量备份是指备份所有宏块。

  • 增量备份是指备份上一次备份以后新增和修改过的宏块。

OceanBase 数据库支持租户级别的恢复，恢复是基于已有数据的备份重建新租户的过程。用户只需要一个 alter system restore tenant 命令，就可以完成整个恢复过程。恢复过程包括租户系统表和用户表的 Restore 和 Recover 过程。Restore 是将恢复需要的基线数据恢复到目标租户的 OBServer，Recover 是将基线对应的日志恢复到对应 OBServer。

OceanBase 数据库目前支持集群级别和租户级别的备份相关操作，且支持手动删除指定的备份和自动清理过期备份的功能。

物理备份架构

OceanBase 数据库物理备份的架构如下图所示。

当用户用系统租户登录到备份集群以后，需要先用 SQL 发起日志归档，等日志归档发起完成启动阶段以后，才可以发起基线备份。

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

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

OceanBase 数据库目前支持使用 OSS 和 NFS 两种文件系统作为备份的目的地。以下是备份功能在备份目的地创建的目录结构以及每个目录下保存的文件类型。

data
  tenant_data_backup_info // 记录租户级别基线备份的信息
  tenant_backup_set_file_info // 比 tenant_data_backup_info 信息更加完整
  backup_set_1_full_date // 一个全量 Backup Set，后缀以日期结尾，例如：backup_set_1_full_20211014
    backup_set_info // 记录本次备份
    single_backup_set_info //记录本次备份，比 backup_set_info 信息更加完整
    backup_1 // 1 为 backup_set_id
      sys_pg_list
      normal_pg_list
      sys_meta_index_file_<task_id>// 系统表的索引，负责根据 pgkey 索引到对应的 PG Meta Files
      normal_meta_index_file_<task_id> // 普通表的索引
      meta_file_<task_id> // 记录 Meta 和宏块列表等信息
    
    data // 不区分版本
      pgkey
        major_data // 基线数据
          macro_block_1.<sub_task_id>   
          macro_block_index_1
          macro_block_2.<sub_task_id>
          macro_block_index_2
        minor_data // 转储数据
          task_id_1
            macro_block_1.<sub_task_id>
            macro_block_index_1
          task_id_2
            macro_block_2.<sub_task_id>
            macro_block_index_2
          
  backup_set_2_inc_date // 一个增量 Backup Set，后缀以日期结尾，例如：backup_set_2_inc_20211014
    backup_set_info // 记录本次备份
    single_backup_set_info 
    backup_2
      sys_pg_list
      normal_pg_list
      sys_meta_index_file_<task_id>
      normal_meta_index_file_<task_id>
      meta_file_<task_id>
    data
      ...
    
clog
  backup_piece_info        // Piece 相关的信息
  tenant_clog_backup_info 
  roundid_pieceid_date   // 例如：1_1_20211014 
    single_piece_info    
    archive_key
      tableid_partition_id  // 例如：1100611139403779_0
      ....
    data
      tableid               // 例如：1100611139403779
        partition_id        // 例如：0
          1                 // 数据文件
          2             
          ...
    index 
      tableid               // 例如：1100611139403779
        partition_id        // 例如：0
          1                 // 索引文件
          2          
          ..

物理恢复架构

OceanBase 数据库的物理恢复架构如下图所示。

对于用户可见的流程主要有两步：

1. 在目的集群上用 CREATE RESOURCE POOL命令建立恢复租户需要的资源池。

2. 通过 ALTER SYSTEM RESTORE TENANT 命令调度租户恢复任务。

   对于备份恢复来说，RESTORE TENANT 命令的内部流程如下：

   1. 创建恢复用的租户。

   2. 恢复租户的系统表数据。

   3. 恢复租户的系统表日志。

   4. 调整恢复租户的元信息。

   5. 恢复租户的用户表数据。

   6. 恢复租户的用户表日志。

   7. 恢复扫尾工作。

      对于单个 PG 来说，恢复的流程就是将 PG 的元信息和宏块数据拷贝到指定的 OBServer，构建出一个只有基线数据的 PG；然后再把 PG 的日志拷贝到指定的 OBServer，回放到该 PG 的 MemTable 中。这个流程中如果日志的量比较大，可能会触发转储操作。