---
title: github-fill
description: 隔离 Zone 为了实现 OceanBase 数据库的高级别容灾功能，我们引入了 Zone 的概念。Zone 是一个逻辑概念，一般是具有相似容灾属性的一组节点的组合。从物理层面来讲，一个 Zone 通常是一个独立的物理部署单元，可以是一个数据中心（IDC）或者云上的一个可用区，也可以是一个单独的机架（Rack）。通过…
---
切换语言

- 中文站 - 简体中文
- International - English
- 日本站 - 日本語

文档反馈![](https://mdn.alipayobjects.com/huamei_22khvb/afts/img/A*P8CuR4UJ_FkAAAAAAAAAAAAADiGDAQ/original) OceanBase 数据库分布式版 - V 4.3.0

# 隔离 Zone

更新时间：2026-04-10 11:58:35

[编辑](https://github.com/oceanbase/oceanbase-doc/edit/V4.3.0/zh-CN/600.manage/100.cluster-management/300.common-cluster-operations/1100.isolation-a-zone.md)  

为了实现 OceanBase 数据库的高级别容灾功能，我们引入了 Zone 的概念。Zone 是一个逻辑概念，一般是具有相似容灾属性的一组节点的组合。从物理层面来讲，一个 Zone 通常是一个独立的物理部署单元，可以是一个数据中心（IDC）或者云上的一个可用区，也可以是一个单独的机架（Rack）。通过将 OceanBase 集群部署于多个 Zone （通常至少 3 个 Zone），实现单个 Zone 故障时的故障隔离及快速恢复。

当需要进行 Zone 级容灾或者 Zone 级运维变更时，可以隔离 Zone。隔离后，新的读写请求不会路由到该 Zone 内的节点上，从而可以隔离故障或者无损的执行运维变更动作。

- 故障隔离场景：例如多机房部署架构下，某机房内有交换机异常，此时部分节点出现丢包、重传，甚至无主选举。为了快速恢复，可以直接隔离该机房对应的 Zone。
 - 运维变更场景：例如 OceanBase 集群升级时采用的轮转升级方案，首先隔离一个 Zone，将用户流量从该 Zone 切到其他 Zone，然后执行升级动作。该 Zone 升级完成后执行 Start 操作恢复流量，再依次升级其他 Zone，从而做到升级对用户透明。

隔离 Zone，只是将用户流量从该 Zone 切走，并没有改变 Paxos 投票成员的数量。不同的隔离命令有不同的安全级别保证，需要根据执行的具体的隔离命令仔细斟酌后续能够安全执行的动作。隔离命令适用于短时间隔离场景，需要持续保持关注，提前做好二次故障的应急预案。如果短时间内恢复不了，可以采用替换 Zone 的方式彻底去除隐患。

隔离 Zone 有以下三种命令，不同的隔离命令有不同的安全级别保证：

- 通过 `STOP ZONE` 命令隔离 Zone
 - 通过 `FORCE STOP ZONE` 命令隔离 Zone
 - 通过 `ISOLATE ZONE` 命令隔离 Zone

通过以上命令成功隔离 Zone 后，Zone 的 `STATUS` 的值变为 `INACTIVE`，表示该 Zone 处于隔离状态。

## STOP ZONE

命令格式如下：

```shell
obclient [(none)]> ALTER SYSTEM STOP ZONE 'zone_name';

```

`STOP ZONE` 是最安全的隔离命令。`STOP Zone` 不但可以将业务流量从该 Zone 切走，实现 Zone 内节点与业务流量隔离的效果，还能保证除被隔离 Zone 以外的其他 Zone 的节点依然能够构成 Paxos 多数派，从而可以安全的对被隔离 Zone 的节点执行任何动作，例如 pstack、调整日志级别等，甚至停止进程。`STOP ZONE` 适用于需要故障隔离和停机运维的场景，是故障隔离和运维变更首选的隔离命令。

为了保证成功执行后可以安全的对被隔离 Zone 内的节点执行任何动作，`STOP ZONE` 命令前置检测比较严格，通过内部各种状态检查，保证目标节点即使停止进程后，集群剩余可用节点的副本仍然能够构成 Paxos 多数派，从而不影响数据库服务的连续性。

`STOP ZONE` 命令限制如下：

1. 不允许同时有多个 Zone 以及多个 Zone 的节点被 Stop，如果已经有其他 Zone 或者其他 Zone 的节点被 Stop，则 `STOP ZONE` 报错 `-4660，cannot stop server or stop zone in multiple zones`。如果遇到该错误信息，可以通过查询 `DBA_OB_SERVERS` 和 `DBA_OB_ZONES`，确认是否存在 Zone 或者节点被 Stop。
 2. `STOP ZONE` 命令通过检查所有租户的所有日志流的 Paxos 成员列表，确认除了目标 Zone 节点和其他非可用节点外，剩余节点上的副本是否依然能够构成 Paxos 多数派。如果不能构成多数派，则不允许执行 `STOP ZONE` 操作。

      1. 非可用节点包括 `INACTIVE`、`stopped`（`ACTIVE` 状态且 `stop_time` 字段大于 0）及 `DELETING` 状态的节点。
      2. 为了检查日志流的 Paxos 成员列表，要求所有日志流都有 Leader，如果发现日志流没有 Leader，则报错 `-4179`，并且展示有问题的日志流信息。

        例如：租户 `1001` 的 1 号日志流没有 Leader，则报错信息为 `Tenant(1001) LS(1) has no leader, stop zone not allowed`。如果遇到该错误信息，可以通过查询 `GV$OB_LOG_STAT` 视图确认日志流的 Leader 副本信息，排查 Leader 副本不正常的问题。
      3. 如果租户的 Locality 属性变更与 `STOP ZONE` 命令并发，为了防止误判，禁止在 Locality 变更过程中 `STOP ZONE`。

        例如：租户 `1001` 正在变更 Locality 减少一个副本，日志流的成员列表正在从 A、B、C 变为 A、B，此时如果需要 Stop B 节点所在的 Zone，`STOP ZONE` 命令可能误判可以被 Stop，从而与减少副本操作冲突。为了避免误判，`STOP ZONE` 命令会报错 `-4179`，并且展示正在变更的租户信息 `Tenant(1001) locality is changing, stop zone not allowed`。如果遇到该错误信息，可以通过查询 `DBA_OB_TENANTS` 视图，确认是否存在租户 Locality 变更操作。
      4. 在排除了目标 Zone 节点和其他非可用节点后，如果剩余节点上的副本不能满足多数派，则报错 `-4179`，并且展示有问题的日志流信息。

        例如：租户 `1001` 的 1 号日志流在 `STOP ZONE` 后不能满足多数派，则报错信息为 `Tenant(1001) LS(1) has no enough valid paxos member after stop zone, stop zone not allowed`。如果遇到该错误信息，可以通过查询 `GV$OB_LOG_STAT` 视图，确认日志流的成员列表和副本信息是否满足多数派。
 3. `STOP ZONE` 保证成功执行后，还能够对被隔离 Zone 内的节点执行任何侵入性动作。即剩余可用节点上的副本在满足多数派的前提下，还要保证剩余可用节点中的多数派副本的日志是同步的，使得被隔离 Zone 内的节点即使停止进程后，剩余节点的日志依然能够形成多数派。

      1. 日志同步判断条件：对比日志流的 Follower 副本和 Leader 副本的最新日志位点，日志位点差距在 5 秒以内即认为日志是同步的。可以通过查询 `GV$OB_LOG_STAT` 视图的 `END_SCN` 字段，获取指定日志流的各个副本的最新日志位点。
      2. 如果不满足该条件，则报错 `-4179`，并且展示有问题的日志流信息。

        例如：租户 `1001` 的 1 号日志流日志不同步，则报错信息为 `Tenant(1001) LS(1) log not sync, stop server not allowed`。如果遇到该错误信息，可以通过查询 `GV$OB_LOG_STAT` 视图的 `END_SCN` 字段确认日志流副本同步情况。

   ```shell
   # 获取指定日志流副本的最新日志位点信息，并转换成时间戳形式
   obclient [(none)]> SELECT SCN_TO_TIMESTAMP(END_SCN) FROM GV$OB_LOG_STAT WHERE TENANT_ID = 1001 and LS_ID = 1;

   ```

`STOP ZONE` 是最安全的隔离命令，但同时它的前置条件也是最严格的。在实际应用中，特别是故障应急场景下，可能无法完全满足上述前置条件，进而导致 `STOP ZONE` 命令无法执行成功。因此 OceanBase 数据库提供了另外两种 Zone 隔离命令：`FORCE STOP ZONE` 和 `ISOLATE ZONE`。他们不同程度的放松了前置检查，减少了限制，从而在更多场景下能够成功隔离 Zone，但 Zone 被隔离后的操作有所限制。任何场景下都应该首选 `STOP ZONE` 命令，`STOP ZONE` 无法成功的情况下可以选择弱化版本的 Zone 隔离命令，但弱化版本的 Zone 隔离后能够执行的操作会有所限制。

## FORCE STOP ZONE

相比于 `STOP ZONE` 命令，`FORCE STOP ZONE` 跳过了日志同步检查。`FORCE STOP ZONE` 命令能够保证将业务流量从被隔离 Zone 内的节点上切走，但不能保证被隔离 Zone 内的节点能够安全的停止进程。强行停止进程后可能破坏 Paxos 多数派，从而影响数据库服务的连续性。

`FORCE STOP ZONE` 的典型应用场景：某机房内的服务器或者网络设备出现硬件异常需要停机运维，为了保证隔离后能够安全的停止进程，我们首选 `STOP ZONE` 命令隔离机房对应的 Zone，但其他 Zone 内的节点的副本日志存在较大延迟，`STOP ZONE` 命令无法执行成功。我们只能退而其次选择 `FORCE STOP ZONE` 命令来隔离 Zone，首先避免硬件异常对业务流量造成影响。然后排查副本日志延迟的原因，待副本日志实时后再次尝试执行 `STOP ZONE` 命令，成功执行后可以安全的进行停机运维。

```shell
obclient [(none)]> ALTER SYSTEM FORCE STOP ZONE zone_name;

```

**注意事项：**

1. 如果在 `FORCE STOP ZONE` 之后，目标 Zone 节点仍然继续参与 Paxos 日志同步，明确不会下线目标 Zone 节点，那么可以安全的使用 `FORCE STOP ZONE`，实现隔离故障以及切换业务流量目的。即使存在部分副本日志不同步，也不会影响服务的连续性。
 2. 如果用户希望在 `FORCE STOP ZONE` 之后下线目标节点，那么用户需要关注存在落后副本的日志流情况，确认目标节点下线后，是否影响该日志流提供服务，用户还可以通过查询 `GV$OB_LOG_STAT` 视图评估服务影响时间。

#### 警告

`FORCE STOP ZONE` 仅仅适用于除了待隔离 Zone 内节点外存在其他节点日志延迟的场景，此时隔离 Zone 的目的仅仅是故障隔离，不能进行任何会造成进程停止的侵入性动作。否则会破坏 Paxos 多数派，造成租户无主，影响数据库服务的连续性。

## ISOLATE ZONE

相比于 `STOP ZONE` 和 `FORCE STOP ZONE`，`ISOLATE ZONE` 的前置检查最为宽松，响应速度最快。它不保证安全性，即不保证目标 Zone 内的节点下线后，集群剩余节点的副本可以组成 Paxos 多数派继续提供服务。

```shell
obclient [(none)]> ALTER SYSTEM ISOLATE ZONE zone_name;

```

`ISOLATE ZONE` 命令前置检查放松逻辑如下：

1. `ISOLATE ZONE` 命令不再限制多个 Zone 的节点同时隔离，如果已经有其他 Zone 的节点被隔离（执行任何一种隔离命令），也可以执行 `ISOLATE ZONE` 命令。

   典型场景：集群有三个 Zone（Z1、Z2、Z3），Z1 和 Z3 各自一个节点出现故障，需要隔离。Z1 故障节点隔离成功后，如果采用 `STOP ZONE` 或者 `FORCE STOP ZONE` 命令继续隔离 Z3 故障节点，会报错不允许同时隔离多个 Zone。此时仅能执行 `ISOLATE ZONE` 命令，将业务流量从故障节点上切走，隔离后不能进行任何会造成进程停止的侵入性动作。
 2. `ISOLATE ZONE` 命令不再检查日志流副本的多数派和日志同步情况，即使不满足相应条件，也可以执行 `ISOLATE ZONE` 命令。

   典型场景：日志流初始的 Paxos 成员列表为 A、B、C 三个节点，C 节点机器宕机后永久下线，日志流的成员列表变更为 A、B，处于缺副本状态。此时如果 B 节点发生硬件故障并希望隔离该节点所在的 Zone，`STOP ZONE` 和 `FORCE STOP ZONE` 均会失败，报错为剩余副本不满足多数派。此时仅能执行 `ISOLATE ZONE` 命令，将业务流量从故障节点上切走，隔离后不能进行任何会造成进程停止的侵入性动作。

`ISOLATE ZONE` 命令限制如下：

当出现多个 Zone 节点被隔离时，`ISOLATE ZONE` 会检查所有租户的 Primary Zone 属性，要求不能同时隔离一个租户 Primary Zone 所在地域的所有 Zone，以防止租户的读写服务切到其他地域，进而业务请求跨城访问导致耗时大幅增加。

可以通过 `DBA_OB_TENANTS` 视图检查租户的 Primary Zone 属性，结合 `DBA_OB_ZONES` 和 `DBA_OB_SERVERS` 视图中已经隔离的 Zone 和节点的信息，确认是否打破上述限制条件。

#### 警告

`ISOLATE ZONE` 仅仅适用于除了待隔离 Zone 内节点外存在其他节点状态异常的场景，此时隔离 Zone 的目的仅仅是故障隔离，不能进行任何会造成进程停止的侵入性动作。否则会破坏 Paxos 多数派，造成租户无主，影响数据库服务的连续性。。

## 总结

任何场景下都应该首选 `STOP ZONE` 命令，成功执行后除了达成故障隔离的目的，还可以保证能够安全的对被隔离 Zone 内节点执行任何应急动作和运维动作。`STOP ZONE` 无法成功的情况下可以选择弱化版本的 Zone 隔离命令，但弱化版本的 Zone 隔离后不能保证能够安全的执行侵入性动作。

`FORCE STOP ZONE` 适用于除了待隔离 Zone 内节点外存在其他节点日志延迟的场景，`ISOLATE ZONE` 适用于除了待隔离 Zone 内节点外存在其他节点状态异常的场景。此时隔离 Zone 的目的仅仅是故障隔离，不能进行任何会造成进程停止的侵入性运维动作，否则会破坏 Paxos 多数派，造成租户无主，影响数据库服务的连续性。

## 相关文档

更多 Zone 相关的运维操作，请参见以下信息：

- [查看 Zone](https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000000639941)
 - [添加 Zone](https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000000639936)
 - [删除 Zone](https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000000639944)
 - [修改 Zone](https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000000639945)
 - [隔离节点](https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000000639934)

 上一篇 下一篇 ![有帮助](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) 咨询热线