OceanBase高可用方案

OceanBase的基本概念

OceanBase 集群、Zone 和 OBServer

一个集群由若干个 OBServer 节点组成，这些 OBServer 节点分属于若干个区（Zone），每个节点属于一个区。区是一个逻辑概念，表示集群内具有相似硬件可用性的一组节点，它在不同的部署模式下代表不同的含义。例如，当整个集群部署在同一个数据中心（IDC）内的时候，一个区的节点可以属于同一个机架，同一个交换机等。当集群分布在多个数据中心的时候，每个区可以对应于一个数据中心。每个区具有 IDC 和地域（Region）两个属性，描述该区所在的 IDC 及 IDC 所属的地域。一般地，地域指 IDC 所在的城市。区的 IDC 和 Region 属性需要反映部署时候的实际情况，以便集群内的自动容灾处理和优化策略能更好地工作。

资源池和租户

集群的多个服务器组成了一个大的资源池，管理员会根据各个租户的要求，创建与之对应的虚拟资源池给租户使用，资源池包括指定规格的 CPU、内存、存储等。为了避免租户之间争抢资源，租户之间的资源相互隔离，内存是物理隔离、CPU 是逻辑隔离。

租户是一个逻辑概念。在 OceanBase 数据库中，租户是资源分配的单位，是数据库对象管理和资源管理的基础，对于系统运维，尤其是对于云数据库的运维有着重要的影响。租户在一定程度上相当于传统数据库的"实例"概念。租户之间是完全隔离的。在数据安全方面，OceanBase 数据库不允许跨租户的数据访问，以确保用户的数据资产没有被其他租户窃取的风险。在资源使用方面，OceanBase 数据库表现为租户"独占"其资源配额。总体上来说，租户（tenant）既是各类数据库对象的容器，又是资源（CPU、Memory、IO 等）的容器。

数据分区和分区副本

OceanBase 数据库参考传统数据库分区表的概念，把一张表格的数据划分成不同的分区（Partition）。在分布式环境下，为保证数据读写服务的高可用，OceanBase 数据库会把同一个分区的数据拷贝到多个机器。不同机器同一个分区的数据拷贝称为副本（Replica）。同一分区的多个副本使用 Paxos 一致性协议保证副本的强一致，每个分区和它的副本构成一个独立的 Paxos 组，其中一个分区为主副本（Leader），其它分区为从副本（Follower）。主副本具备强一致性读和写能力，从副本具备弱一致性读能力。

OceanBase整理架构

OceanBase高可用架构

• 服务器（Server）级无损容灾：能够容忍单台服务器不可用，自动无损切换。
• 机房（Zone）级无损容灾：能够容忍单个机房不可用，自动无损切换。
• 地区（Region）级无损容灾：能够容忍某个城市整体不可用，自动无损切换。

数据分区和分区副本概述

OceanBase 数据库参考传统数据库分区表的概念，把一张表格的数据划分成不同的分区（Partition）。在分布式环境下，为保证数据读写服务的高可用，OceanBase 数据库会把同一个分区的数据拷贝到多个机器。不同机器同一个分区的数据拷贝称为副本（Replica）。同一分区的多个副本使用 Paxos 一致性协议保证副本的强一致，每个分区和它的副本构成一个独立的 Paxos 组，其中一个分区为主分区（Leader），其它分区为备分区（Follower）。主分区具备强一致性读和写能力，备分区具备弱一致性读能力。

两阶段提交

OceanBase 数据库实现了原生的两阶段提交协议，保证分布式事务的原子性。

两阶段提交协议中包含两种角色，协调者（Coordinator）和参与者（Participant）。协调者负责整个协议的推进，使得多个参与者最终达到一致的决议。参与者响应协调者的请求，根据协调者的请求完成 prepare 操作及 commit/abort 操作。

分布式事务提交流程

传统和 OceanBase 数据库两阶段提交的流程如下图所示。

PREPARE 阶段

协调者：协调者向所有的参与者发起 prepare request

参与者：参与者收到 prepare request 之后，决定是否可以提交，如果可以则持久化 prepare log 并且向协调者返回 prepare 成功，否则返回 prepare 失败。

COMMIT阶段

协调者：协调者收齐所有参与者的 prepare ack 之后，进入 COMMIT 状态，向用户返回事务 commit 成功，然后向所有参与者发送事务 commit request。

参与者：参与者收到 commit request 之后释放资源解行锁，然后提交 commit log，日志持久化完成之后给协调者回复 commit ok 消息，最后释放事务上下文并退出。

数据同步模式

OceanBase 数据库支持以下两种传输模式：

• 强同步模式SYNC

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

最大保护和最大可用模式下，主集群仅支持配置一个 SYNC 模式的备集群。最大性能模式下，该传输模式不生效，用户可以配置任意数量的备集群为 SYNC 模式。

主集群可以将自己配置为 SYNC 模式，只有当自己切换为备集群时才有意义。最大保护和最大可用模式下，执行 switchover 前，要求将主集群配置为 SYNC 模式，保证 switchover 之后，仍然存在一个 SYNC 模式的备集群。

• 异步同步模式 ASYNC

该模式下，主集群的 REDO 日志会异步同步到目标备集群。事务的提交时延不受目标备集群影响。

OceanBase 集群高可用方案简介

容灾部署方案

部署方案	容灾能力	RTO	RPO
同机房三副本	机器级无损容灾 / 机架级无损容灾	30s 内	0
同城双机房主备库	机房级容灾	分钟级	大于 0
同城三机房	机房级无损容灾	30s 内	0
两地两中心主备库	地域级容灾	分钟级	大于 0
三地三中心五副本	地域级无损容灾	30s内	0

同城三机房三副本部署

特点

• 同城 3 个机房组成一个集群（每个机房是一个 Zone），机房间网络延迟一般在 0.5 ~ 2 ms 之间。
• 机房级灾难时，剩余的两份副本依然是多数派，依然可以同步 Redo-Log 日志，保证 RPO=0。
• 无法应对城市级的灾难。

部署方案示图

三地五中心五副本部署

特点

• 三个城市，组成一个 5 副本的集群。
• 任何一个 IDC 或者城市的故障，依然构成多数派，可以确保 RPO=0。
• 由于 3 份以上副本才能构成多数派，但每个城市最多只有 2 份副本，为降低时延，城市 1 和城市 2 应该离得较近，以降低同步 Redo-Log 的时延。
• 为降低成本，城市 3 可以只部署日志型副本（只有日志）。

部署方案示图

说明

同城三机房或者三地五中心的方案对基础设施要求太高。为了利旧企业现网的基础设施，OceanBase 提供了同城两机房和两地三中心两种方案。

同城两机房"主-备"部署

特点

• 每个城市都部署一个 OceanBase 集群，一个为主集群一个为备集群；每个集群有自己单独的 Paxos group，多副本一致性。
• "集群间"通过 Redo-log 做数据同步，形式上类似传统数据库"主从复制"模式；有"异步同步"和"强同步"两种数据同步模式，类似 ODD 中的"最大性能"和"最大保护"两种模式。

部署方案示图

两地三中心"主-备"部署

特点

• 主城市与备城市组成一个 5 副本的集群。任何 IDC 的故障，最多损失 2 份副本，剩余的3份副本依然满足多数派。
• 备用城市建设一个独立的 3 副本集群，做为一个备集群，从主集群"异步同步"或者"强同步"到备集群。
• 一旦主城市遭遇灾难，备城市可以接管业务。

部署方案示图