体验高可用与故障切换

高可用是分布式数据库的可靠性基础。OceanBase 数据库采用 Shared-Nothing 的分布式架构，数据以多副本方式存储在多个节点上，通过基于 Multi-Paxos 的分布式共识协议保证副本间数据的一致性。当节点发生宕机等故障时，系统能够自动选举新的主副本并继续提供服务，无需人工干预，容灾能力可以达到 RPO=0、RTO<8 秒。

本文将引导您完成以下体验：

• 理解高可用架构：掌握 Zone、副本、日志流、Leader/Follower、Paxos 多数派等核心概念。
• 观察副本与 Leader 分布：通过系统视图查看日志流副本的位置、角色与同步状态。
• 模拟进程异常：强制终止 observer 进程，观察服务可用性的变化。
• 体验服务恢复与数据零丢失：重新拉起进程恢复服务，验证故障前后数据完整一致。

前提条件

在开始本文操作前，确保满足以下条件：

高可用架构简介

OceanBase 数据库的体系架构和实现方式，保证了数据的强一致性、完整性和高可用。理解以下核心概念有助于开展后续体验：

在 OceanBase 数据库中，用户的读写请求由日志流的 Leader 副本提供服务：所有修改都会产生日志，并通过 Multi-Paxos 协议同步给其他 Follower 副本。当 Leader 所在节点发生故障时，一个 Follower 会被选举为新的 Leader 并继续提供服务。选举服务是高可用的基石：在 V4.x 版本中，选举服务的粒度是日志流，且不再依赖 NTP 等外部时钟同步服务，而是通过本地时钟以及经过改进的租约机制来保证一致性。

观察副本与 Leader 分布

日志流具有位置信息（分布于哪些节点）和角色信息（LEADER 还是 FOLLOWER），本节在 sys 租户中通过系统视图查看集群中所有租户的日志流副本分布情况。

操作步骤

1. 使用 root 用户登录集群的 sys 租户（密码为部署时随机生成的密码，获取方式见上文前提条件）：

   obclient -h127.0.0.1 -uroot@sys -P2881 -p -A oceanbase
   

2. 通过 CDB_OB_LS_LOCATIONS 视图查看所有租户的日志流副本分布：

   obclient [oceanbase]> SELECT TENANT_ID, LS_ID, SVR_IP, ZONE, ROLE, PAXOS_REPLICA_NUMBER, REPLICA_TYPE
                       FROM oceanbase.CDB_OB_LS_LOCATIONS;
   

   返回结果示例如下（示例环境已创建用户租户 ha_tenant 并在其中建表，实际租户 ID 因创建顺序而异；如果您刚完成部署、尚未创建用户租户或业务表，此处返回的行数会更少，属正常现象）：

   +-----------+-------+-----------+-------+--------+----------------------+--------------+
   | TENANT_ID | LS_ID | SVR_IP    | ZONE  | ROLE   | PAXOS_REPLICA_NUMBER | REPLICA_TYPE |
   +-----------+-------+-----------+-------+--------+----------------------+--------------+
   |         1 |     1 | 127.0.0.1 | zone1 | LEADER |                    1 | FULL         |
   |      1001 |     1 | 127.0.0.1 | zone1 | LEADER |                    1 | FULL         |
   |      1002 |     1 | 127.0.0.1 | zone1 | LEADER |                    1 | FULL         |
   |      1002 |  1001 | 127.0.0.1 | zone1 | LEADER |                    1 | FULL         |
   +-----------+-------+-----------+-------+--------+----------------------+--------------+
   4 rows in set
   

   对结果的关键字段解读如下：

   字段	结果解读
   TENANT_ID	租户 ID。1 为 sys 租户；每个用户租户都会伴随一个 Meta 租户（系统内部租户，用于存储和管理租户自身的元数据信息，用户无法直接访问），可通过 DBA_OB_TENANTS 视图中 META$ 开头的租户名识别。示例中 1001 为 Meta 租户、1002 为用户租户 ha_tenant。
   LS_ID	日志流 ID。每个租户都有 1 号系统日志流；用户租户创建后并不会立即有用户日志流，在租户中创建用户表后，系统会自动创建 1001 号及之后的用户日志流，业务数据存储在用户日志流上（示例中 1002 号租户的 1001 号日志流即为其建表后出现）。
   SVR_IP / ZONE	副本所在节点与 Zone。单节点集群所有副本均位于同一节点、同一 Zone。
   ROLE	副本角色，均为 LEADER：单副本日志流没有 Follower，其唯一副本就是 Leader。
   PAXOS_REPLICA_NUMBER	Paxos 副本数，均为 1。多副本集群中该值通常为 3（或 5），此时同一日志流会输出多行，分布在不同的节点与 Zone 上，其中只有一行 ROLE 为 LEADER。
   REPLICA_TYPE	副本类型。FULL 为全功能型副本，拥有 RedoLog、MemTable 和 SSTable 等全部完整数据和功能，是必选副本。

3. 通过 V$OB_LOG_STAT 视图查看日志流的角色与同步状态：

   obclient [oceanbase]> SELECT TENANT_ID, LS_ID, SVR_IP, SVR_PORT, ROLE, PAXOS_REPLICA_NUM, IN_SYNC
                       FROM oceanbase.V$OB_LOG_STAT;
   

   在系统租户中查询此视图时，将展示所有租户日志流的状态。返回结果示例如下：

   +-----------+-------+-----------+----------+--------+-------------------+----------+
   | TENANT_ID | LS_ID | SVR_IP    | SVR_PORT | ROLE   | PAXOS_REPLICA_NUM | IN_SYNC  |
   +-----------+-------+-----------+----------+--------+-------------------+----------+
   |         1 |     1 | 127.0.0.1 |     2882 | LEADER |                 1 | YES      |
   |      1001 |     1 | 127.0.0.1 |     2882 | LEADER |                 1 | YES      |
   |      1002 |     1 | 127.0.0.1 |     2882 | LEADER |                 1 | YES      |
   |      1002 |  1001 | 127.0.0.1 |     2882 | LEADER |                 1 | YES      |
   +-----------+-------+-----------+----------+--------+-------------------+----------+
   4 rows in set
   

   V$OB_LOG_STAT 展示的是日志流 Palf（基于 Paxos 的日志模块）的状态，常用于查询日志流是否有 Leader、成员列表及副本同步状态。结果中 ROLE 为 LEADER 表示该副本是日志流的主副本；IN_SYNC 为 YES 表示副本与 Leader 完全同步。

模拟进程异常并观察服务恢复

本节模拟 observer 进程异常崩溃的场景（例如进程被操作系统强制终止），观察服务可用性的变化，然后重新拉起进程恢复服务，并验证故障前后数据的一致性。

操作步骤

1. 创建体验租户并准备验证数据。在 sys 租户中执行以下命令创建租户 ha_tenant（租户与资源池的详细说明请参见 体验多租户与资源隔离，如已有业务租户也可直接复用）：

   obclient [oceanbase]> CREATE RESOURCE UNIT ha_unit MAX_CPU=1, MIN_CPU=1, MEMORY_SIZE='2G';
   obclient [oceanbase]> CREATE RESOURCE POOL ha_pool UNIT='ha_unit', UNIT_NUM=1, ZONE_LIST=('zone1');
   obclient [oceanbase]> CREATE TENANT IF NOT EXISTS ha_tenant CHARSET='utf8mb4', PRIMARY_ZONE='zone1', RESOURCE_POOL_LIST=('ha_pool') SET ob_tcp_invited_nodes='%';
   

2. 使用 root 用户登录 ha_tenant（新创建租户的 root 用户默认密码为空，出现密码输入提示时直接回车即可），创建测试表并写入数据：

   obclient -h127.0.0.1 -uroot@ha_tenant -P2881 -p -A test
   

   obclient [test]> CREATE TABLE ha_demo_order (id INT PRIMARY KEY, item VARCHAR(50), amount DECIMAL(10,2));
   Query OK, 0 rows affected
   
   obclient [test]> INSERT INTO ha_demo_order VALUES (1, 'keyboard', 149.00), (2, 'mouse', 79.00), (3, 'monitor', 999.00);
   Query OK, 3 rows affected
   
   obclient [test]> SELECT COUNT(*) FROM ha_demo_order;
   +----------+
   | COUNT(*) |
   +----------+
   |        3 |
   +----------+
   1 row in set
   

   记录当前的行数 3 作为故障前的基线。保持当前 obclient 会话不要退出，后续将直接观察该会话在故障期间的表现。

3. 新开一个终端，查找 observer 进程并强制终止，模拟进程异常崩溃：

   # 查找 observer 进程
   ps -ef | grep observer | grep -v grep
   
   # 强制终止 observer 进程（PID 以上一步查询结果为准）
   kill -9 <PID>
   

4. 回到 ha_tenant 的会话，再次执行查询：

   obclient [test]> SELECT COUNT(*) FROM ha_demo_order;
   ERROR 2013 (HY000): Lost connection to MySQL server during query
   No connection. Trying to reconnect...
   ERROR 2002 (HY000): Can't connect to OceanBase server on '127.0.0.1' (115)
   

   连接已中断，客户端尝试自动重连也失败，服务不可用。此时新开连接同样会失败：

   obclient -h127.0.0.1 -uroot@ha_tenant -P2881 -p -A test
   ERROR 2002 (HY000): Can't connect to OceanBase server on '127.0.0.1' (115)
   

   单副本集群的唯一节点故障后，没有其他副本可以接管服务，服务将持续不可用，直到进程被重新拉起。

5. 在终端中重新拉起集群（obd demo 部署的集群部署名固定为 demo；如集群未通过 obd 管理，请按部署时记录的启动命令重新启动 observer 进程）：

   obd cluster restart demo
   

   等待命令执行完成、各组件状态变为 running。

6. 回到 ha_tenant 的会话，再次执行查询。客户端将自动重新连接，并返回结果：

   obclient [test]> SELECT COUNT(*) FROM ha_demo_order;
   No connection. Trying to reconnect...
   Connection id:    3221700101
   Current database: test
   
   +----------+
   | COUNT(*) |
   +----------+
   |        3 |
   +----------+
   1 row in set
   

   查询恢复正常，行数与故障前基线一致，数据零丢失。输出中的 Connection id 为重连后新会话的连接 ID（数值因环境而异），Current database 表示重连后仍处于原来的数据库上下文。这是因为在单副本模式下，事务提交同样要求 RedoLog 持久化到磁盘后才返回成功，进程异常崩溃不会丢失任何已提交事务。

结果解读

多副本集群的故障切换

本文的单节点环境为单副本部署，节点故障时服务中断并依赖人工恢复。而在生产环境常见的三副本集群中（3 个 Zone 各部署一个 OBServer 节点），同样的节点故障表现完全不同：

在三副本集群中，每个日志流的 3 个副本分布在 3 个 Zone 的不同节点上，构成一个 Paxos 组，同一时刻只有 1 个 Leader 对外提供读写服务。当 Leader 所在节点宕机时：

1. 剩余的 2 个副本构成多数派，数据不丢失、多数派日志依然可提交；
2. 选举服务在剩余副本中快速选举出新的 Leader（租约超时后触发，通常在秒级完成）；
3. 业务的后续请求被路由到新 Leader，服务自动恢复，无需人工干预；
4. 故障节点恢复重新加入集群后，Root Service 会自动补齐缺失的副本，恢复三副本状态。

下一步

完成本文的高可用与故障切换体验后，您可以继续以下探索之旅：

1. 体验水平扩展与弹性伸缩：探索计算、存储和租户资源层面的扩展能力，观察扩容前后的资源变化与业务容量影响，参见 体验水平扩展与弹性伸缩。
2. 体验并行导入与高压缩：使用并行导入能力完成大批量入库，并对比压缩前后的存储占用，参见 体验并行导入与高压缩。
3. 深入多租户与资源隔离：在一个集群中为不同业务创建相互隔离的租户，参见 体验多租户与资源隔离。

相关文档

• 高可用的体系架构、Multi-Paxos 协议与选举服务的详细介绍请参见 高可用架构概述。
• 副本概念、副本类型（全功能型/只读型）的详细介绍请参见 副本介绍。
• 分区、分片、日志流与副本的关系请参见 日志流和副本概述。
• 查看日志流副本分布的视图说明请参见 DBA_OB_LS_LOCATIONS 和 CDB_OB_LS_LOCATIONS。
• 查看日志流角色与同步状态的视图说明请参见 V$OB_LOG_STAT。
• 多节点集群的部署方法请参见 使用命令行部署 OceanBase 数据库生产环境。