隔离节点

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

• 故障隔离场景：节点发生异常时，需要将异常节点与业务流量隔离开来。例如，某机房内有交换机异常，此时某些节点出现丢包、重传，甚至无主选举。为了快速恢复，可以直接隔离这些异常节点。节点恢复后执行 Start 操作恢复节点流量。

• 运维变更场景：节点需要运维变更时，需要保证对业务流量的透明无感。例如，某节点服务器需要重启时，为了保证重启过程中不影响业务流量，可以执行节点隔离动作，从而将待重启服务器上的业务流量切到其他节点。重启动作完成后执行 Start 操作恢复节点流量。

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

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

• 通过 STOP SERVER 命令隔离节点

• 通过 FORCE STOP SERVER 命令隔离节点

• 通过 ISOLATE SERVER 命令隔离节点

使用上述命令成功隔离节点后，被隔离节点的 STATUS 字段仍为 ACTIVE 不变，但 STOP_TIME 字段的值由 NULL 变为隔离操作的时间点，表示该节点处于 Stopped 状态。

STOP SERVER

命令格式如下，一次支持 Stop 多台 server。

obclient [(none)]> ALTER SYSTEM STOP SERVER 'svr_ip1:svr_port1', 'svr_ip2:svr_port2', ...;

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

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

STOP SERVER 命令限制如下：

1. 不允许同时有多个 Zone 的节点被 Stop，如果同时 Stop 了多个 Zone 的节点，或者已经有其他 Zone 的节点被 Stop，则报错 -4660，cannot stop server or stop zone in multiple zones。如果遇到该错误信息，可以通过查询 DBA_OB_SERVERS 和 DBA_OB_ZONES 视图，确认是否存在多个 Zone 的节点被 Stop。

2. STOP SERVER 命令通过检查所有租户的所有日志流的 Paxos 成员列表，确认除了目标节点和其他非可用节点外，剩余节点上的副本是否依然能够构成 Paxos 多数派。如果不能构成多数派，则不允许执行 Stop Server 操作。

   1. 非可用节点包括：INACTIVE、Stopped（ACTIVE 状态且 stop_time 字段大于 0）及 DELETING 状态的节点。

   2. 为了检查日志流的 Paxos 成员列表，要求所有日志流都有 Leader，如果发现日志流没有 Leader，则报错 -4179，并且展示有问题的日志流信息。

      例如：租户 1001 的 1 号日志流没有 Leader，则报错信息为 Tenant(1001) LS(1) has no leader, stop server not allowed。如果遇到该错误信息，可以通过查询 GV$OB_LOG_STAT 视图确认日志流的 Leader 副本信息，排查 Leader 副本不正常的问题。

   3. 如果租户的 Locality 属性变更命令与 STOP SERVER 命令并发执行，为了防止误判，禁止在 Locality 变更过程中 Stop 节点。

      例如：租户 1001 正在变更 Locality 减少一个副本，日志流的成员列表正在从 A、B、C 变为 A、B，此时如果需要 Stop B 节点，STOP SERVER 命令可能误判 B 节点可以被 Stop，从而与减少副本操作冲突。为了避免误判，STOP SERVER 命令会报错 -4179，并且展示正在变更的租户信息 Tenant(1001) locality is changing, stop server not allowed。如果遇到该错误信息，可以通过查询 DBA_OB_TENANTS 视图，确认是否存在租户 Locality 变更操作。

   4. 在排除了目标节点和其他非可用节点后，如果剩余节点上的副本不能满足多数派，则报错 -4179，并且展示有问题的日志流信息。

      例如：租户 1001 的 1 号日志流在 Stop 节点后不能满足多数派，则报错信息为 Tenant(1001) LS(1) has no enough valid paxos member after stop server, stop server not allowed。如果遇到该错误信息，可以通过查询 GV$OB_LOG_STAT 视图，确认日志流的成员列表和副本信息是否满足多数派。

3. STOP SERVER 保证成功执行后，还能够对被隔离节点执行任何侵入性动作。即剩余可用节点上的副本在满足多数派的前提下，还要保证剩余可用节点中的多数派副本的日志是同步的，使得被隔离节点即使停止进程后，剩余节点的日志依然能够形成多数派。

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

FORCE STOP SERVER

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

FORCE STOP SERVER 的典型应用场景：A、B、C 三个节点，B 节点的副本日志存在较大延迟，例如 1 个小时。此时节点 C 出现硬件异常需要停机运维。为了保证隔离后能够安全的停止进程，我们首选 STOP SERVER 命令隔离节点，但由于 B 节点的副本日志存在较大延迟，STOP SERVER 命令无法执行成功。我们只能退而其次选择 FORCE STOP SERVER 命令来隔离节点，首先避免硬件异常对业务流量造成影响。然后排查 B 节点日志延迟的原因，待 B 节点日志实时后再次尝试执行 STOP SERVER 命令，成功执行后可以安全的进行停机运维。

obclient [(none)]> ALTER SYSTEM FORCE STOP SERVER 'svr_ip1:svr_port1', 'svr_ip2:svr_port2', ...;

ISOLATE SERVER

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

obclient [(none)]> ALTER SYSTEM ISOLATE SERVER 'svr_ip1:svr_port1', 'svr_ip2:svr_port2', ...;

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

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

   典型场景：集群有三个 Zone（Z1、Z2、Z3），Z1 和 Z3 各自一个节点出现故障，需要隔离。Z1 故障节点隔离成功后，如果采用 STOP SERVER 或者 FORCE STOP SERVER 命令继续隔离 Z3 故障节点，会报错不允许同时隔离多个 Zone。此时仅能执行 ISOLATE SERVER 命令，将业务流量从故障节点上切走，隔离后不能进行任何会造成进程停止的侵入性动作。

2. ISOLATE SERVER 命令不再检查日志流副本的多数派和日志同步情况，即使不满足相应条件，也可以执行 ISOLATE SERVER 命令。

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

ISOLATE SERVER 命令限制如下：

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

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

总结

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

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

相关文档

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

• 查看节点

• 重启节点

• 添加节点

• 删除节点

• 替换节点