暂无图片
暂无图片
1
暂无图片
暂无图片
暂无图片

基于官方文档的OceanBase 知识学习-备份与恢复- (基于官方文档做记录 V2.2.77版本)

原创 lxs_data 2022-01-03
1478

     本文是基于OceanBase V2.2.77版本 官方文档 做的学习记录,主要是目的是进行OBCP 考试,通过学习文档,希望了解OceanBase知识,最终考过OBCP。go! 

     本文内容大部分都是OceanBase 官网资料,做了一些比较显著的标志。

         

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

       OceanBase 数据库支持集群级别的物理备份。物理备份由两种数据组成:基线数据、日志归档数据。

                                                                                                  物理备份:日志归档、  数据备份两个功能组合

        日志归档:日志数据的自动归档功能,OBServer 会定期将日志数据归档到指定的备份路径全自动的,不需要外部定期触发。

        数据备份:备份基线数据的功能,分为:全量备份和增量备份两种:

                                                                    全量备份:指备份所有的需要基线的宏块。

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

         OceanBase 数据库支持租户级别的恢复,恢复是基于已有数据的备份重建新租户的过程

                           用户只执行 alter system restore tenant 命令,就可以完成整个恢复的过程。

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

                                                                                    Restore :将恢复需要的基线数据恢复到目标租户的 OBServer

                                                                                    Recover :将基线对应的日志恢复到对应的 OBServer

                         手动删除指定的备份和自动过期备份

备份架构

           OceanBase 数据库物理备份的架构:

                       物理备份架构

        用户用系统租户登录到备份集群先用 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 数据库物理恢复的架构:

                   Image

 用户可见的流程主要有两步:

  1. 目的集群使用 CREATE RESOURCE POOL 命令建立恢复租户需要的 resource pool。

  2. 使用 ALTER SYSTEM RESTORE TENANT 命令调度租户恢复任务

对于备份恢复,restore tenant 命令内部流程如下:

  1. 创建恢复用的租户   ---创建租户

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

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

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

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

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

  7. 恢复扫尾工作                ---恢复扫尾

         对于单个 PG 来说,恢复的流程:

             将 PG 的元信息和宏块数据拷贝到指定的 OBServer,构建出一个只有基线数据的 PG;然后再把 PG 的日志拷贝到指定的 OBServer回放到该 PG 的 memtable 中

             这个流程中如果日志的量比较大,可能会触发转储操作

Backup Set 管理

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

            对于全量备份:会建立一个独立的元信息目录和一个宏块的目录

           对于增量备份:会建立一个独立的元信息目录,但是会重用对应全量备份的宏块目录。

                                   增量备份包含了完整的元信息只重用的宏块数据,不会影响恢复的性能。

          备份管理的时候全量备份和其对应的若干增量备份是作为一个管理单元的不允许单独删除一组备份里面的单个增量备份或者单个全量备份。

Archive Log Round

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

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













「喜欢这篇文章,您的关注和赞赏是给作者最好的鼓励」
关注作者
【版权声明】本文为墨天轮用户原创内容,转载时必须标注文章的来源(墨天轮),文章链接,文章作者等基本信息,否则作者和墨天轮有权追究责任。如果您发现墨天轮中有涉嫌抄袭或者侵权的内容,欢迎发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。

评论