容灾架构及容灾级别

概述

用户可以通过灵活调整集群各个 Zone 的机房和 Region 分布，以及租户副本在这些 Zone 上的分布，从而调整租户的部署模式，达到不同的容灾级别。

OceanBase 数据库支持的容灾等级如下所示。

三种部署模式示意图如下所示：

• 同城三中心部署模式

  

• 两地三中心部署模式

  

• 三地五中心部署模式

  

OceanBase 数据库的部署模式通过租户级别的 Locality 属性来描述，我们在《副本管理》章节中描述了三种部署模式的 Locality 示例，通过调整租户的 Locality 属性，从而达到灵活的部署模式，进而达到不同的容灾级别。详细信息参见 Locality 介绍。

多副本技术的容灾架构，其核心逻辑是通过 Paxos 协议保证事务日志达成多数派提交。如果发生故障的节点小于多半数，选举协议能够保证自动恢复，且 RPO = 0。如果多于半数的节点发生故障，就需要人工介入，可以通过单副本的方式拉起服务，由于少数派可能没有包含最新的数据，因此可能会丢失最后一部分数据。

在金融行业里，传统关系型数据库往往也部署成“两地三中心”架构，同城两个机房，一个主库，一个热备，异地一个冷备。虽然可以通过数据库原生的半同步机制来保证业务更新的同时也提交到备库，但并不是强保证机制，当主库出现故障时，备库依然可能没有最新的更新，并且强制将备库切为主库可能会导致数据丢失。这就意味着，传统关系型数据库的“两地三中心”架构要么选择高可用，要么选择强一致，无法打破 “CAP 理论”。但 OceanBase 数据库基于 Paxos 协议的多副本容灾技术真正做到了同城和异地的无损容灾，达到 RPO = 0，RTO < 8 秒。

通过 OceanBase 数据库的多副本技术实现的容灾架构，应用只需要感知一个数据源，数据库内部复制的细节对应用完全透明。同时，它提供了单机级、机房级、甚至城市级故障的无损容灾能力，并且恢复时间小于 8 秒。

单机容灾

OceanBase 数据库内部的心跳机制能够自动处理节点异常，OBProxy 也能够感知节点异常状态，从而避免应用层对节点异常状态的感知。为了避免节点的非通断型故障引起的乒乓效应持续短暂影响应用，应该第一时间隔离异常节点，隔离异常节点的相关操作可参见 隔离节点；如果隔离节点后自动产生的 Leader 不是最优，您可以通过主动切主的方式将 Primary Zone 切到指定 Zone，主动切主的详细操作请参见 数据库层高可用。

对于故障节点的后续处理，分为以下两种场景：

• 故障 OBServer 可以重新启动

  不论故障机器之前处于何种心跳状态，OBServer 重新启动后，OBServer 与 Root Service 之间的心跳数据包恢复以后，OBServer 可重新提供服务。重启 OBServer 的详细操作请参见 重启节点。

• 故障 OBServer 损坏，无法重新启动

  在确认 OBServer 损坏无法重新启动后，需要走机器替换流程，即下线故障节点，并重新上线新机器。有关替换机器的详细操作请参见 替换节点。

机房容灾

机房级容灾要求集群部署满足多机房部署条件，例如，同城三中心和两地三中心。该部署模式下，任何机房故障导致少数派副本不可用时，剩下的多数派副本依然可以继续提供服务，保证零数据丢失。如果机房故障仅影响到单个 Zone，您可以通过 Stop Zone 的方式隔离故障副本，通过 Stop Zone 隔离故障 Zone 的相关操作请参见 隔离 Zone；如果机房故障影响到多个 Zone，您可以通过主动切主的方式将 Leader 切换到指定 Zone，主动切主的详细操作请参见 数据库层高可用。

城市容灾

城市级容灾要求集群部署满足多城市部署条件，例如，三地五中心。该部署模式下，任意一个城市故障，最多损失两个副本，剩下的多数派副本依然可以继续提供服务，保证零数据丢失。如果自动选举产生的 Leader 不是最优，或者为了避免城市级故障的间隙性影响，您可以通过切主的方式将 Leader 切换到最优 Zone，主动切主的详细操作请参见 数据库层高可用。