隔离 Zone

为了实现 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

命令格式如下：

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 字段确认日志流副本同步情况。

   # 获取指定日志流副本的最新日志位点信息，并转换成时间戳形式
   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 命令，成功执行后可以安全的进行停机运维。

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 视图评估服务影响时间。

ISOLATE ZONE

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

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 和节点的信息，确认是否打破上述限制条件。

总结

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

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

相关文档

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

• 查看 Zone

• 添加 Zone

• 删除 Zone

• 修改 Zone

• 隔离节点