【数据库】从操作上描述 OceanBase 的高可用与容灾

对于所有具体的相关操作请自行查看官方操作手册。

闪回

回收站

OceanBase提供回收站，主要用于存储用户删除的数据库和表等信息。

在当前版本中，支持进入回收站的对象有索引、表、库和租户，各模式回收站对象的支持情况如下表所示。

模式	索引（Index）	表（T able）	数据库（Dat abase）	租户（Tenant ）
MySQL	支持	支持	支持	支持
Oracle	支持	支持	不支持	不支持

• 直接 DROP 索引不会进入回收站，删除表时，表上的索引会随主表一起进入回收站。
• 不能对回收站的对象做任何查询和 DML 操作，DDL 操作中也仅支持 Purge 和 Flashback 操作。

闪回回收对象

使用限制：

• 在恢复表时，Flashback 对象的顺序需要符合从属关系，即先 Flashback 数据库，再 Flashback 表。
• 通过 FLASHBACK 语句恢复表时，表上的索引也会恢复。
• 通过 PURGE 命令可以单独清除索引，但是 FLASHBACK 命令不支持单独恢复索引。
• 如果一张表在进入回收站前属于某个表组，通过闪回恢复后该表默认会恢复到该表组中；如果表组已经被删除，则该表恢复后会不属于任何一个表组。

Restore Point

在很多应用系统中，用户需要查询数据库中的某个时间点，或者特定版本的数据来完成一些数据分析或汇总之类的操作。

OceanBase 数据库在 V2.2.7x 版本中提供了 Restore Point 功能，允许用户在租户上创建 Restore Point，将历史版本的数据保存下来。Restore Point 功能类似于租户的快照点，可以通过闪回查询的方式来访问特定版本的历史数据。

当前 Restore Point 功能的使用限制如下：

• 不支持物理备份。
• 不支持主备库。
• 不支持在 sys 租户下创建 Restore Point。
• 每个租户内最多可创建 10 个 Restore Point 。
• 创建 Restore Point 后，如果对创建 Restore Point 前就存在的表执行 DDL 语句，对于 MySQL 模式，系统会报 ERROR 4179 (HY000): restore point exist, create index/alter not allowed 的错误；对于 Oracle 模式，系统会报 ORA-00600: internal error code, arguments: -4179, restore point exist, create index/alter not allowed 的错误。

由于 Restore Point 功能依赖 GTS 维护全局的一致性快照，故在使用 Restore Point 时，需要开启 GTS。

闪回查询多数据库版本

OceanBase 数据库提供了记录级别的闪回查询（Flashback Query）功能，该功能允许用户获取某个历史版本的数据。

其中，Oracle 模式支持 AS OF SCN 和 AS OF TIMESTAMP 两种语法来查询；MySQL 模式支持通过 AS OF SNAPSHOT 语法来查询。

备份恢复管理

概述

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

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

OceanBase 数据库从 V2.2.52 版本开始支持集群级别的物理备份。物理备份由基线数据、日志归档数据两种数据组成，因此物理备份由日志归档和数据备份两个功能组合而成：

• 日志归档是指日志数据的自动归档功能，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 为单位进行管理。

物理恢复架构

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

1. 在目的集群上用 CREATE RESOURCE POOL 命令建立恢复租户需要的资源池。
2. 通过 ALTER SYSTEM RESTORE TENANT 命令调度租户恢复任务。

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

在执行备份操作前，如果需要使用 NFS 软件作为备份目的地，可参考本节内容部署 NFS。
一般建议使用 OSS 或者专用的 NFS 硬件设备，可以考虑使用阿里云的 NFS 硬件设备。

备份成功后，可以根据业务需要，开启自动清理功能，系统会自动清理已过期的备份数据。当前仅支持集群级别备份数据的自动清理。

备份备份的数据

备份备份是对备份数据和日志备份的再次备份。OceanBase 数据库支持集群级别和租户级别的备份备份操作。

基本概念

• 源端备份：表示通过配置项 backup_dest 设置的备份目的端。
• 目的备份：表示通过配置项 backup_backup_dest 设置的备份目的端。
• 备份备份：表示将原备份文件再次备份到新的备份路径。
• 备份备份日志：表示将原日志备份文件再次备份到新的备份路径。
• 备份备份数据：表示将原数据备份文件再次备份到新的备份路径。
• 日志分片（Piece）：表示将备份日志按照指定时间段切换目录。
• 断流：由于源端备份中备份的日志被清理而导致这个 Round 的日志数据无法被正常执行备份备份的数据的行为。
• Round：表示一轮完整的备份数据流。对于切分 Piece 的场景，Round 中包含若干
• Piece；对于不切分 Piece 的场景，Round 中只包含一个 Piece。当前 OceanBase 数据库支持集群级别和租户级别的切 Piece 功能。

使用限制：在执行备份备份操作时，需要保证源端备份中至少有一份有效备份数据。

数据校验

在 OceanBase 数据库中，备份数据的校验主要是对数据的有效性和完整性进行校验。数据的有效性主要是指数据文件是否有 bit 翻转等情况，可以通过计算 Checksum校验和来判断数据的有效性。数据的完整性主要是指数据文件是否有丢失。

当前主要支持以下几种场景的数据校验：

• 本集群内备份数据的校验
• 本集群内指定路径备份或备份备份数据的校验
• 跨集群指定路径备份或备份备份数据的校验

注意事项：在校验备份数据前，请确认待校验的数据满足以下条件。

• 所有备份数据均为备份成功的数据。
• 仅支持校验未被清理的备份数据。

恢复数据

在执行恢复操作前，您需要执行一些恢复前的准备操作，包括创建资源、设置加密信息、打开恢复配置等。

执行全量恢复

恢复会先根据用户输入的命令，从备份目的端将需要的宏块数据从对应的全量备份和增量备份中恢复到目标租户，然后再拉取和回放事务日志。

场景示例信息

在某些使用场景下（例如，跨城部署场景），由于备份介质的访问问题，会导致集群中某些 OBServer 无法访问备份介质，此时需要您通过设置 backup_zone 配置项，指定哪些 OBServer 可以备份。

以两地三中心的部署架构为例，部署架构图如下图所示。

图中，OceanBase 数据库主库的 5 副本跨越了 3 个机房和 2 个城市，即 2（深圳南山）+2（深圳宝安）+1（杭州）的模式。正常情况下，Leader 主要集中在南山的 2 个Zone 里。假设备份介质 NFS 部署在深圳南山机房，可以跨同城机房访问 NFS，但不允许跨城市访问 NFS，则南山和宝安机房的 OBServer 可以访问 NFS，且南山机房的 OBServer 访问 NFS 属于同机房访问，而宝安机房的 OBServer 访问 NFS 会产生跨机房网络流量；杭州机房的 OBServer 则无法访问 NFS。

主备库管理

主备库概述

OceanBase 集群的多副本机制提供了丰富的容灾能力，在机器级、机房级、城市级故障情况下，可以实现自动切换，并且不丢失数据，即 RPO = 0。

OceanBase 数据库的主备库高可用架构是 OceanBase 数据库高可用能力的重要补充。当主集群出现计划内或计划外（多数派副本故障）的不可用情况时，备集群可以接管服务，并且提供无损切换（RPO = 0）和有损切换（RPO > 0）两种容灾能力，最大限度降低服务的停机时间。

OceanBase 数据库支持创建、维护、管理及监控一个或多个备集群。备集群是生产库数据的热备份。管理员可以选择将资源密集型的报表操作分配到备集群，以便提高系统的性能和资源利用率。

主备库配置

OceanBase 主备库配置支持 1 个主集群和最多 31 个备集群。可以采用 SQL 命令或 OCP 来管理主集群和备集群。

主集群即生产集群，是唯一接受业务写入和强一致性读的集群，它的角色是 PRIMARY。
备集群是主集群的一个数据备份，用于保证事务的一致性，它的角色是 PHYSICAL STANDBY。

主集群会自动向备集群传输 REDO 日志，备集群收到 REDO 日志后会进行持久化，然后执行 REDO 回放操作，恢复用户数据和 Schema，保证与主集群物理一致。

OceanBase 数据库还提供了多种数据校验机制，通过多种途径保证备集群恢复的数据与主集群数据的一致性，包括：

• 数据恢复校验机制
  • 日志项 Checksum校验：保证每一条日志都准确
  • 日志累积 Checksum校验：保证不漏掉一条日志
  • 事务级别 Checksum校验：保证事务修改的完整性
  • 行级别 Checksum校验：保证每一行修改的完整性
• 多副本数据校验机制
  • 列 Checksum校验：保证副本间每一列值的一致性
  • 分区数据 Checksum和行数校验：保证副本间分区数据的一致性
• 索引表和主表数据校验机制
  • 列 Checksum校验：保证索引表和主表的列数据一致
  • 行数校验：保证索引表和主表的数据量一致
• 跨集群数据校验机制
  • 分区数据 Checksum和行数校验：保证主备集群间分区数据的一致性

注意事项

• 备集群不能主动触发大版本冻结
  • 备集群同步了主集群的 Major Freeze 冻结信息，只有主集群才能发起 Major Freeze 操作，备集群根据主集群的冻结信息调度合并操作。但是备集群可以自己触发 Minor Freeze，与主集群无关。
  • 如果备集群的大版本信息同步落后，可能会导致备集群的系统租户同步卡住。
• 备集群不能落后太多
  • 备集群长时间落后的情况下，内部会自动执行重建操作拉取主集群上的全量数据，然后从最新的日志点开始同步日志。这个过程会导致内部多版本数据空洞，从而导致Failover 失败和备集群读失败，待备集群追上主集群后即可恢复服务。

部署前提条件

部署备集群前，您需要了解以下信息：

• 部署备集群时，系统会自动从主集群同步全量数据，整个过程对带宽有要求，在正常同步过程中，仅同步 REDO 日志，相当于加了一个备副本。
• 备集群的版本一般要求与主集群版本一致，如果需要升级版本，OCP 支持主备集群滚动升级，即一次升级任务中会同时升级主集群和备集群，升级顺序为先升级备集群，再升级主集群。

租户管理

在 OceanBase 数据库中，系统租户可以对普通租户进行管理。主备集群之间的系统租户是相互独立的，不会物理同步数据，但是备集群会感知主集群普通租户的变化，保证同步所有普通租户的数据。备集群从主集群的系统租户逻辑同步的租户管理操作包括创建租户、删除租户和重命名租户。

备集群也支持独立进行部分的租户管理操作，当前支持在主备集群上独立运维的租户管理操作如下：

• 管理租户的资源配置
• 管理租户的资源池
• 管理租户的 Locality 配置
• 管理租户的 Primary Zone 配置

此外，主备库配置下，主备集群均不支持物理恢复租户。

日志传输服务

OceanBase 数据库的日志传输服务负责自动将主集群的 REDO 日志传输到备集群，它提供了以下能力：

• 主集群向备集群传输 REDO日志
• 在备集群落后的情况下，自动从主集群拉取 REDO 日志
• 管理所有备集群的同步参数，支持级联传输日志

传输模式

OceanBase 数据库支持以下两种传输模式，每个备集群均需要独立配置：

• 强同步模式（SYNC）
  该模式下，主集群的 REDO 日志要强同步到目标备集群。一条 REDO 日志要等主集群和 SYNC 模式的备集群都持久化成功后才认为持久化成功。事务的提交时延会增加主备集群的网络延时和备集群持久化日志的时间。
• 异步同步模式（ASYNC）
  该模式下，主集群的 REDO 日志会异步同步到目标备集群。事务的提交时延不受目标备集群的影响。

日志传输和级联策略

OceanBase 数据库是多日志流系统，默认情况下，每个分区一个日志流。主备集群之间以日志流为单位同步日志，不同日志流之间相互独立。

以单个分区的日志流为例，主集群分区的主副本生成日志后，会同步给本集群的多数派版本，并且等待多数派持久化成功。此时，如果没有需要强同步的备集群，则系统立即返回日志持久化成功；如果有需要强同步的备集群，则主集群的主副本会给备集群的主副本发送日志，然后等待备集群的主副本应答成功后才返回日志持久化成功。同时，备集群的主副本收到日志后，会同步给本集群的多数派副本，待本集群的多数派持久化成功后，就会应答主集群的主副本成功。

综上所述，强同步模式下，备集群直接从主集群的主副本同步日志，不能自由选择上游副本。但是对于异步同步的备集群，OceanBase 数据库提供了按 Region 级联的传输日志策略，备集群可以就近选择上游副本，即备集群可以优先选择同 Region 的主集群的副本或者同 Region 的其他备集群副本作为上游副本。

异步同步模式下，OceanBase 数据库提供的按 Region 级联的传输日志策略，能够尽可能地保证跨 Region 部署场景下，仅传输一份日志，降低跨 Region 的网络带宽占用。

下图所示为备集群级联主集群同 Region 的副本的场景，其中：

• 主集群跨 Region 部署，多数派副本均部署在 Region SH 中，少数派副本部署在 Region HZ，主副本部署在 Region SH 中。
• 备集群 S1 部署在 Region SH 中，配置为强同步模式，直接由主集群的主副本强同步日志给备集群的主副本。
• 备集群 S2 部署在 Region HZ 中，配置为异步同步模式，由于主集群在 HZ 有一个副本，备集群会自动级联到主集群在 Region HZ 的副本下；主集群在 Region HZ 的副本从主副本同步日志，备集群的主副本从主集群在 Region HZ 的副本异步同步日志。

下图所示为备集群级联备集群的场景，其中：

• 备集群 S1 和备集群 S2 都配置为异步同步模式，主集群在 Region HZ 中没有副本。
• 备集群 S1 会跨地域从主集群的主副本异步同步日志。
• 备集群 S2 由于和备集群 S1 部署在相同的 Region，故会自动选择备集群 S1 作为上游副本，从备集群 S1 的主副本异步同步日志。

保护模式

保护模式概述

OceanBase 数据库支持三种保护模式。

保护模式类型：

• 最大性能模式（MaximumPerformance）
  • 该模式为默认的保护模式。
  • 它在最大限度地确保主集群性能的同时，还能保护用户的数据。在这种保护模式下，事务只需要等待 REDO 日志在主集群持久化成功就可以立即提交。REDO 日志会异步地同步到备集群，但是不会阻塞主集群事务的提交。因此，主集群的性能不会受备集群的同步延时影响。
• 最大保护模式（MaximumProtection）
  • 该模式提供了最高级别的数据保护，可以确保主集群出现故障时不会发生数据丢失。在这种保护模式下，事务在提交之前需要等待 REDO 日志在主集群和强同步的备集群上都持久化成功才能提交。
  • 最大保护模式下仅支持配置一个强同步的备集群，其他备集群只能处于异步同步模式。如果强同步的备集群不可用，主集群会停止写服务。
• 最大可用模式（MaximumAvailability）
  • 该模式在不损失集群可用性的前提下提供了最高级别的数据保护。
  • 默认情况下，事务需要等待 REDO 日志在主集群和强同步的备集群上都持久化成功后才能提交。当感知到强同步的备集群出现故障时，主集群不用再等待日志强同步成功，和最大性能模式一样优先恢复主集群服务，保证集群可用性。直到强同步的备集群恢复服务后，主集群会自动恢复为强同步模式，提供最高级别的数据保护。
  • 最大可用模式下仅支持配置一个强同步的备集群，其他备集群只能处于异步同步模式。

保护模式与保护级别

保护模式功能本质上用于定义主集群以何种模式（强同步或异步同步）向不同的备集群传输日志，备集群以何种方式接收日志以及数据是否无损。

OceanBase 数据库提供了两个字段来描述保护模式的配置及主备集群的状态：

• 保护模式（ PROTECTION_MODE ）
• 保护级别（ PROTECTION_LEVEL ）

接着将从以下两个场景来描述这两个字段的取值及其含义。

最大性能模式切换为最大保护模式场景：

默认情况下，主集群和备集群均处于最大性能模式，主集群异步向所有备集群传输日志，备集群数据落后于主集群，数据是有损的。主集群和备集群的保护模式和保护级别均显示为 MAXIMUM PERFORMANCE 。

最大保护模式下，主集群会强同步日志给 SYNC 备集群， SYNC 备集群最终会达到数据无损状态。整个模式过程不是原子的，会存在中间状态。下图展示了从最大性能模式切换为最大保护模式时，< PROTECTION_MODE ， PROTECTION_LEVEL >二元组状态的转换流程。

最大性能模式切换为最大可用模式的场景：

最大可用模式是最大性能和最大保护两种保护模式的结合。最大可用模式下，主集群会存在两种状态：强同步日志给 SYNC 备集群和异步同步日志给 SYNC 备集群，两种状态会动态变化，同时影响备集群的状态。下图展示了从最大性能模式切换为最大可用模式时，
< PROTECTION_MODE ， PROTECTION_LEVEL > 二元组状态的转换流程。

角色切换

切换前准备

获取集群信息：查询 V$OB_CLUSTER 视图，获取各个集群的角色、状态、保护模式和保护级别。

选择切换方式：角色切换操作主要包括以下两种。

• Switchover
  • 在主集群可用的情况下，允许主集群与其中一个备集群交换角色，保证数据无损。
  • Switchover 包括两个阶段：主集群切换为备集群和备集群切换为主集群。
• Failover
  • 表示在主集群不可用情况下，将一个备集群角色切换为主集群角色。
  • Failover 操作又分为无损 Failover 和有损 Failover。

选择待切换的备集群：当存在多个备集群时，需要选择合适的备集群作为待切换的目标集群。主要考虑以下几点：

• 备集群的地域。
  根据业务需要来确定主集群的地域，从而确定切换成新主集群的备集群的地域。
• 备集群的硬件配置，包括 CPU、I/O 带宽等。
  考虑备集群的硬件配置是否满足业务需求。
• 备集群的同步进度延迟应尽量小。
  最大性能模式下，备集群落后越多，Switchover 切换的时间越长，Failover 后丢失的数据越多，故建议选择同步进度延迟小的备集群。
• 备集群的保护模式和保护级别是否符合要求。
  最大保护和最大可用模式下，Switchover 仅支持日志传输模式为 SYNC 的备集群切换为主集群角色；Failover 也需要根据保护模式和保护级别选择合适的 Failover 命令。

注意事项及影响

执行 Failover 流程的注意事项及影响：

• 对集群状态的要求
  • 对于主集群，要求主集群的所有 OBServer 全部宕机，避免双写，同时也是保证无损 Failover 场景下原主集群接入到新主集群的必要条件。
  • 对于即将执行有损 Failover 的备集群，要求所有的 OBServer 都处于 ACTIVE 状态，否则会导致 Failover 命令执行失败。
  • 如果备集群为 INACTIVE 状态的 OBServer 都处于永久下线状态，您也可以添加 FORCE 关键字，强制 执行有损 Failover。语句如下：

  obclient> ALTER SYSTEM ACTIVATE PHYSICAL STANDBY CLUSTER FORCE;
  

• 对保护模式的影响
  Failover 流程对保护模式有影响，即无论操作前属于何种保护模式，执行 Failover 操作后，集群将统一被 设置为最大性能模式。需要重新调整保护模式的配置。
• 对索引的影响
  Failover 过程会特殊处理索引。OceanBase 数据库会自动删除执行 Failover 操作后未生效的索引和多余的索引。在无损 Failover 场景下，会存在原主集群上已经生效的索引，但在新主集群上会被删除。这是因为备集群的索引为异步构建，与主集群不同步。即使是无损 Failover 也无法保证索引无损。
• 对副本的影响
  • Failover 过程不能处理正在创建中的副本。备集群创建分区时会从主集群同步元数据，如果主集群不可用，备集群正在创建中的副本可能会一直处于 standby restore 状态。
  • 如果存在正在创建中的副本，可能导致 Failover 过程卡住直到超时。为了确保 Failover 操作能顺利完成，建议备集群执行 Failover 前通过以下 SQL 语句检查处于standby restore 状态的分区副本。

执行无损 Failover 流程

1. 确认主集群处于不可用状态，即主集群上的所有 OBServer 均已宕机。
2. 在各个备集群上查询保护模式和保护级别，选择合适的备集群。
3. 执行以下命令，将备集群无损切换为主集群。

   obclient> ALTER SYSTEM FAILOVER TO 'obcluster' CLUSTER_ID=2;
   

   Failover 命令执行后，集群会默认进入最大性能模式，原主集群和其他备集群均处于 DISABLED 状态，需要执行接入操作。
4. （可选）触发合并。
   无损 Failover 执行成功后，如果集群的合并版本为 1 ，建议发起一轮合并，并且等待合并成功后再添加新的备集群，否则新添加的备集群会工作异常，不能执行 Switchover 等操作。

执行无损 Failover 后原主集群接入流程

前提条件:在操作前，您需要根据执行无损 Failover 操作前原主集群的状态来判断是否能够重新接入建立主备关系.

• 初始时，如果原主集群处于最大保护模式，备集群处于最大保护级别。当主集群不可用时，备集群执行无损 Failover，这种场景下原主集群可以接入。
• 初始时，如果原主集群处于最大保护模式，备集群处于最大保护级别，同时主备集群网络隔离，主集群人工修改保护模式后，继续提供服务，备集群仍然处于最大保护级别。当主集群不可用时，备集群执行无损 Failover，这种场景下原主集群不能接入。
• 初始时，如果原主集群处于最大可用模式，主集群和备集群均处于最大可用级别，当主集群不可用时，备集群执行无损 Failover，这种场景下原主集群可以接入。
• 初始时，如果原主集群处于最大可用模式，主集群和备集群均处于最大可用级别，同时主备集群网络隔离，主集群自动降级为最大性能级别异步同步日志，备集群仍然处于最大可用级别。当主集群不可用时，备集群执行无损 Failover，这种场景下原主集群不能接入。

注意：原主集群接入时，由于接入流程不会完整校验数据的一致性，需要人工保证执行 Failover 操作前主备集群的数据一致。如果执行 Failover 操作前主备集群数据不一致，接入后可能会出现数据 Checksum校验错误。

操作步骤：确认可接入后，原主集群的接入流程如下。

1. 恢复原主集群。
2. 将原主集群切换为备集群角色。
3. 在新主集群上，开启原主集群同步。

执行无损 Failover 后其他备集群接入

操作步骤：在新主集群上，开启其他备集群的同步。

1. 登录新主集群，执行以下命令，开启备集群同步。
2. 查看同步状态，确认开启成功。

执行有损 Failover 流程

1. 使用 root 用户登录数据库的 sys 租户。确认主集群处于不可用状态，即主集群上的所有 OBServer 均已宕机。

说明：为了保证安全，要求主备集群中只能存在一个真正的主集群。如果主集群可用，则在备集群上执行Failover 命令会报错。因此，在执行 Failover 命令前，需要确认主集群处于不可用状态，避免后续 Failover 命令执行失败。

2. 在各个备集群上查询集群状态，选择合适的备集群作为目标主集群。
3. 选择备集群后，登录备集群，修改配置项，加快 Failover 的速度。
4. 在备集群上，切换为主集群。
5. 查询 V$OB_CLUSTER 和 V$OB_CLUSTER_FAILOVER_INFO 视图，观察集群状态，确定 Failover 切换位点。
6. 恢复配置项的值。

注意：如果执行 Failover 前修改了配置项，Failover 执行完成后请务必恢复配置项的值，以免影响后续集群的正常工作。

执行有损 Failover 后续操作

执行有损 Failover 后，新主集群与原主集群以及其他备集群的数据会不一致，不支持接入原主集群和其他备集群。如果您想恢复主备关系，需要执行重建流程。

执行有损 Failover 后其他集群的恢复流程：

1. 在新主集群上删除原主集群或其他备集群，清除集群数据。
2. 在其他集群的机器上，搭建新的备集群，建立新的主备关系。
3. 待新的备集群实时同步后，执行 Switchover，切换主备角色。建议选择同步进度延迟小的备集群切换为新主集群。

执行 Failover 后数据的订正流程：

执行有损 Failover 或无损 Failover 后，新主集群相比原主集群可能会丢失一部分数据，OceanBase 数据库提供了集群的只读模式功能，方便订正新主集群与原主集群的数据。

1. 在原主集群的所有 Server 上，指定特殊参数 -m disabled_with_readonly_cluster ，启动 observer。
2. 原主集群启动后，查看集群状态，确认进入 DISABLED WITH READ ONLY 状态即只读模式状态。
   原主集群以只读模式启动后，会进行自我隔离，即不会从新主集群或者其他备集群同步数据，自身也不会向其他集群同步数据，保证数据安全性。在用户侧，普通租户仅支持读操作，不支持写入和 DDL 操作，并且保证数据冻结在 Failover 之前的快照版本。
3. 登录集群的普通租户，订正新主集群与原主集群的数据。
   OceanBase 数据库默认开启了强一致性读，不需要特殊配置，直接订正数据即可。

备集群读服务

备集群各个分区的全功能型副本或者只读副本会实时回放 REDO 日志，并且能够承载读服务。OceanBase 数据库支持单分区读和跨分区一致性读，始终保证读取结果是一个快照，从而保证事务的一致性。

由于不同分区以及不同副本的回放进度不同，默认情况下，可能导致先后两次读取的
数据版本出现回退的情况。因此，OceanBase 数据库提供了单调读开关。开启单调读开关后，内部会维护租户级别单调递增的可读版本号，每次读取时都会获取全局最新的可读版本号作为快照版本，保证读取的数据越来越新，不会回退。

同时，OceanBase 数据库支持有界旧（Bounded Staleness）一致性读，保证读取的数据不会落后于主集群最新数据的特定时间，默认为 5 秒。如果备集群落后超过阈值，则读操作会重试等待，直到超时或者备集群追上。

注意：备集群的普通租户仅支持弱一致性读，如果发起强一致性读、写或者 DDL 操作，则会报错。