--- title: "体验高可用与故障切换 - OceanBase 数据库 V5.0.1 | OceanBase 文档中心" description: 体验高可用与故障切换 高可用是分布式数据库的可靠性基础。OceanBase 数据库采用 Shared-Nothing 的分布式架构，数据以多副本方式存储在多个节点上，通过基于 Multi-Paxos 的分布式共识协议保证副本间数据的一致性。当节点发生宕机等故障时，系统能够自动选举新的主副本并继续提供服务，无需人工干预… image: https://mdn.alipayobjects.com/huamei_22khvb/afts/img/A*OSPzQ6GUQF4AAAAAQHAAAAgAeiGDAQ/original --- 切换语言 - 中文站 - 简体中文 - International - English - 日本站 - 日本語 文档反馈![](https://mdn.alipayobjects.com/huamei_22khvb/afts/img/A*P8CuR4UJ_FkAAAAAAAAAAAAADiGDAQ/original) OceanBase 数据库分布式版 - V 5.0.1 # 体验高可用与故障切换 更新时间：2026-10-27 15:56:46 [编辑](https://github.com/oceanbase/oceanbase-doc/edit/V5.0.1/zh-CN/200.quickstart/600.experience-high-availability-and-failover.md) 高可用是分布式数据库的可靠性基础。OceanBase 数据库采用 Shared-Nothing 的分布式架构，数据以多副本方式存储在多个节点上，通过基于 Multi-Paxos 的分布式共识协议保证副本间数据的一致性。当节点发生宕机等故障时，系统能够自动选举新的主副本并继续提供服务，无需人工干预，容灾能力可以达到 RPO=0、RTO<8 秒。 本文将引导您完成以下体验： - **理解高可用架构**：掌握 Zone、副本、日志流、Leader/Follower、Paxos 多数派等核心概念。 - **观察副本与 Leader 分布**：通过系统视图查看日志流副本的位置、角色与同步状态。 - **模拟进程异常**：强制终止 observer 进程，观察服务可用性的变化。 - **体验服务恢复与数据零丢失**：重新拉起进程恢复服务，验证故障前后数据完整一致。 #### 说明 本文基于 OceanBase 数据库 V5.0.1（社区版）撰写，文中相关命令和功能说明均以 V5.0.1 版本为准。本文以 [部署 OceanBase](https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000006615008) 中使用 All in One 安装包部署的**单节点**环境为例。单节点集群中的租户为单副本（每个日志流只有 1 个副本），因此本文体验的是"观察副本与 Leader 分布 + 模拟进程异常 + 服务恢复"。多副本集群在节点故障时自动切换主副本的能力，需要至少 3 节点集群，本文将在[多副本集群的故障切换](#多副本集群的故障切换)一节说明其行为，您也可以参考 [使用命令行部署 OceanBase 数据库生产环境](https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000006615498) 部署多节点集群深入体验。 ## 前提条件 在开始本文操作前，确保满足以下条件： | 项目 | 描述 | | --- | --- | | OceanBase 数据库 | 已使用 All in One 安装包完成部署并成功启动（部署名为 `demo`），参见 [部署 OceanBase](https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000006615008)。 | | 机器资源 | 建议不低于 4 核 CPU、16 GB 内存。 | | sys 租户访问 | 可使用 root 用户登录集群的 sys 租户执行管理操作。sys 租户 root 用户的密码为部署时随机生成的密码，可在部署输出或 `obd cluster display demo` 命令的输出中查看。 | | obclient | 已安装 obclient 并可正常连接 OceanBase 数据库。使用 All in One 安装包部署时已自动安装。 | | 多租户基础（可选） | 本文会创建一个体验租户，租户与资源池的概念参见 [体验多租户与资源隔离](https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000007140973)。 | ## 高可用架构简介 OceanBase 数据库的体系架构和实现方式，保证了数据的强一致性、完整性和高可用。理解以下核心概念有助于开展后续体验： | 概念 | 说明 | | --- | --- | | 集群（Cluster）与 Zone | 一个 OceanBase 集群由若干个 Zone 组成，一个 Zone 由多台物理机器组成，每台物理机器称之为数据节点（OBServer 节点）。一个分区（或日志流）的多个副本分散在多个不同的 Zone 里，从而实现服务器级、机房级甚至地区级的容灾能力。 | | 副本（Replica） | 同一份数据在不同节点的拷贝。OceanBase 以 Paxos 协议的多副本架构作为高可用能力的基础，在少数派副本故障的情况下依然能够提供无损的数据库服务。 | | 日志流（Log Stream，LS） | 由 OceanBase 数据库自动创建和管理的实体，代表一批数据的集合，包括若干数据分区及对其进行事务操作的日志和事务管理结构。每个日志流和它的副本构成一个独立的 Paxos 组。 | | 主副本（Leader）/ 从副本（Follower） | 多个副本中有且只有一个副本接受修改操作，叫做主副本（Leader），其他叫做从副本（Follower）。Leader 提供强一致读写服务，Follower 提供弱一致读服务，并在 Leader 故障时可快速切换为 Leader。 | | 多数派（Paxos） | 事务提交时，日志需要在多数派副本上持久化成功。任意少数派副本故障时，数据不会丢失、服务不会停止，系统总是可以自动选择新的副本作为主副本继续提供服务。 | | Primary Zone | 租户级配置，指定 Leader 优先分布的 Zone。选举服务的优先级机制会参考 Primary Zone 及机器的异常状态等，选择更优的副本作为主副本。 | 在 OceanBase 数据库中，用户的读写请求由日志流的 Leader 副本提供服务：所有修改都会产生日志，并通过 Multi-Paxos 协议同步给其他 Follower 副本。当 Leader 所在节点发生故障时，一个 Follower 会被选举为新的 Leader 并继续提供服务。选举服务是高可用的基石：在 V4.x 版本中，选举服务的粒度是日志流，且不再依赖 NTP 等外部时钟同步服务，而是通过本地时钟以及经过改进的租约机制来保证一致性。 #### 说明 根据部署方式的不同，OceanBase 可以实现服务器（Server）级、机房（Zone）级、地区（Region）级无损容灾。详细信息请参见 [高可用架构概述](https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000006616440)。 ## 观察副本与 Leader 分布 日志流具有位置信息（分布于哪些节点）和角色信息（LEADER 还是 FOLLOWER），本节在 sys 租户中通过系统视图查看集群中所有租户的日志流副本分布情况。 ### 操作步骤 1. 使用 root 用户登录集群的 sys 租户（密码为部署时随机生成的密码，获取方式见上文前提条件）： ```shell obclient -h127.0.0.1 -uroot@sys -P2881 -p -A oceanbase ``` 2. 通过 `CDB_OB_LS_LOCATIONS` 视图查看所有租户的日志流副本分布： ```sql 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 因创建顺序而异；如果您刚完成部署、尚未创建用户租户或业务表，此处返回的行数会更少，属正常现象）： ```shell +-----------+-------+-----------+-------+--------+----------------------+--------------+ | 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` 视图查看日志流的角色与同步状态： ```sql obclient [oceanbase]> SELECT TENANT_ID, LS_ID, SVR_IP, SVR_PORT, ROLE, PAXOS_REPLICA_NUM, IN_SYNC FROM oceanbase.V$OB_LOG_STAT; ``` 在系统租户中查询此视图时，将展示所有租户日志流的状态。返回结果示例如下： ```shell +-----------+-------+-----------+----------+--------+-------------------+----------+ | 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 完全同步。 #### 说明 在多副本集群中，以上两个视图会为同一日志流输出多行记录（每个副本一行）：`CDB_OB_LS_LOCATIONS` 的 `MEMBER_LIST` 字段展示成员列表，`V$OB_LOG_STAT` 的 `PAXOS_MEMBER_LIST` 字段展示 Paxos 成员列表，多行中仅一行 `ROLE` 为 `LEADER`，其余为 `FOLLOWER`。通过租户的 `DBA_OB_LS_LOCATIONS` 视图（不带 `CDB` 前缀）可查看本租户视角的副本分布。详细信息请参见 [DBA_OB_LS_LOCATIONS](https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000006617370) 和 [V$OB_LOG_STAT](https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000006617582)。 ## 模拟进程异常并观察服务恢复 本节模拟 observer 进程异常崩溃的场景（例如进程被操作系统强制终止），观察服务可用性的变化，然后重新拉起进程恢复服务，并验证故障前后数据的一致性。 ### 操作步骤 1. 创建体验租户并准备验证数据。在 sys 租户中执行以下命令创建租户 `ha_tenant`（租户与资源池的详细说明请参见 [体验多租户与资源隔离](https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000007140973)，如已有业务租户也可直接复用）： ```sql 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 用户默认密码为空，出现密码输入提示时直接回车即可），创建测试表并写入数据： ```shell obclient -h127.0.0.1 -uroot@ha_tenant -P2881 -p -A test ``` ```sql 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 进程并强制终止，模拟进程异常崩溃： ```shell # 查找 observer 进程 ps -ef | grep observer | grep -v grep # 强制终止 observer 进程（PID 以上一步查询结果为准） kill -9 ``` 4. 回到 `ha_tenant` 的会话，再次执行查询： ```sql 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) ``` 连接已中断，客户端尝试自动重连也失败，服务不可用。此时新开连接同样会失败： ```shell 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) ``` 单副本集群的唯一节点故障后，没有其他副本可以接管服务，服务将持续不可用，直到进程被重新拉起。 #### 说明 报错信息可能因客户端版本与连接方式略有差异，例如部分环境下显示 `ERROR 2003 (HY000): Can't connect to MySQL server on '127.0.0.1:2881' (111)`。无论具体报错为何，核心现象一致：已有连接断开、新连接无法建立，说明服务当前不可用。 5. 在终端中重新拉起集群（`obd demo` 部署的集群部署名固定为 `demo`；如集群未通过 obd 管理，请按部署时记录的启动命令重新启动 observer 进程）： ```shell obd cluster restart demo ``` 等待命令执行完成、各组件状态变为 `running`。 6. 回到 `ha_tenant` 的会话，再次执行查询。客户端将自动重新连接，并返回结果： ```sql 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 持久化到磁盘后才返回成功，进程异常崩溃不会丢失任何已提交事务。 #### 注意 - `kill -9` 仅用于本文的体验场景，**生产环境严禁直接强杀 observer 进程**。生产环境的运维操作请参见官网《OceanBase 数据库》文档中的运维管理章节。 - 进程恢复时间取决于集群启动耗时（包含 Redo 回放等流程）。从执行 `obd cluster restart` 到服务恢复通常在分钟级以内，本文实测直接重新拉起进程的场景下从进程启动到服务恢复约 15 秒。恢复期间请耐心等待，无需重复执行拉起命令。 - 如需观察恢复后的副本状态，可在服务恢复后重新执行本文**观察副本与 Leader 分布**一节中的视图查询，确认各日志流 `ROLE` 恢复为 `LEADER`、`IN_SYNC` 为 `YES`。 ### 结果解读 | 观察项 | 预期现象 | 说明 | | --- | --- | --- | | **故障期间已有会话** | 执行 SQL 报错 `ERROR 2013`，连接中断 | 服务进程崩溃，所有连接断开 | | **故障期间新建连接** | 连接失败（如 `ERROR 2002` / `ERROR 2003`） | 唯一节点不可用，无副本可接管 | | **恢复后服务** | obclient 自动重连成功，查询正常返回 | 进程重新拉起后，日志流恢复服务 | | **恢复后数据** | 行数与故障前基线一致，零丢失 | 已提交事务的 RedoLog 已持久化，重启后数据完全恢复 | ## 多副本集群的故障切换 本文的单节点环境为单副本部署，节点故障时服务中断并依赖人工恢复。而在生产环境常见的三副本集群中（3 个 Zone 各部署一个 OBServer 节点），同样的节点故障表现完全不同： | 对比项 | 单副本集群（本文环境） | 三副本集群（多节点部署） | | --- | --- | --- | | 节点故障时服务 | 中断 | 不中断，自动无损切换 | | 恢复方式 | 人工执行 `obd cluster restart` | 自动选举新 Leader，继续提供服务 | | 恢复指标 | 取决于人工介入时间 | RPO=0（数据零丢失），RTO<8 秒 | | 数据丢失 | 已提交数据不丢失 | 已提交数据不丢失（多数派持久化） | 在三副本集群中，每个日志流的 3 个副本分布在 3 个 Zone 的不同节点上，构成一个 Paxos 组，同一时刻只有 1 个 Leader 对外提供读写服务。当 Leader 所在节点宕机时： 1. 剩余的 2 个副本构成多数派，数据不丢失、多数派日志依然可提交； 2. 选举服务在剩余副本中快速选举出新的 Leader（租约超时后触发，通常在秒级完成）； 3. 业务的后续请求被路由到新 Leader，服务自动恢复，无需人工干预； 4. 故障节点恢复重新加入集群后，Root Service 会自动补齐缺失的副本，恢复三副本状态。 #### 说明 如需亲身体验多副本自动切换，可参考 [使用命令行部署 OceanBase 数据库生产环境](https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000006615498) 部署 3 节点集群后，停掉任意一个节点并观察 `CDB_OB_LS_LOCATIONS` 视图中 Leader 的迁移，以及业务连接的自动恢复情况。 ## 下一步 完成本文的高可用与故障切换体验后，您可以继续以下探索之旅： 1. **体验水平扩展与弹性伸缩**：探索计算、存储和租户资源层面的扩展能力，观察扩容前后的资源变化与业务容量影响，参见 [体验水平扩展与弹性伸缩](https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000007140975)。 2. **体验并行导入与高压缩**：使用并行导入能力完成大批量入库，并对比压缩前后的存储占用，参见 [体验并行导入与高压缩](https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000007140976)。 3. **深入多租户与资源隔离**：在一个集群中为不同业务创建相互隔离的租户，参见 [体验多租户与资源隔离](https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000007140973)。 ## 相关文档 - 高可用的体系架构、Multi-Paxos 协议与选举服务的详细介绍请参见 [高可用架构概述](https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000006616440)。 - 副本概念、副本类型（全功能型/只读型）的详细介绍请参见 [副本介绍](https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000006615212)。 - 分区、分片、日志流与副本的关系请参见 [日志流和副本概述](https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000006616455)。 - 查看日志流副本分布的视图说明请参见 [DBA_OB_LS_LOCATIONS](https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000006617370) 和 [CDB_OB_LS_LOCATIONS](https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000006617227)。 - 查看日志流角色与同步状态的视图说明请参见 [V$OB_LOG_STAT](https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000006617582)。 - 多节点集群的部署方法请参见 [使用命令行部署 OceanBase 数据库生产环境](https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000006615498)。 上一篇 下一篇 ![有帮助](https://gw.alipayobjects.com/mdn/ob_asset/afts/img/A*y6ocSqN8cqsAAAAAAAAAAAAAARQnAQ)![无帮助](https://gw.alipayobjects.com/mdn/ob_asset/afts/img/A*BG9IQJyLHF8AAAAAAAAAAAAAARQnAQ)![反馈](https://gw.alipayobjects.com/mdn/ob_asset/afts/img/A*eTWdQKCRKHwAAAAAAAAAAAAAARQnAQ)[AI](https://www.oceanbase.com/obi) 咨询热线