---
title: 两地三中心五副本架构下，同城两机房网络故障后的应急预案注意事项-OceanBase数据库使用指南
description: 了解OceanBase数据库在实际应用中关于两地三中心五副本架构下，同城两机房网络故障后的应急预案注意事项相关的常见问题和使用技巧，帮助您快速解决两地三中心五副本架构下，同城两机房网络故障后的应急预案注意事项的难题。
---
切换语言

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

划线反馈

# 两地三中心五副本架构下，同城两机房网络故障后的应急预案注意事项

更新时间：2026-06-08 02:41

适用版本： V2.1.x、V2.2.x、V3.1.x、V3.2.x 内容类型：Troubleshoot  

本文简述在两地三中心五副本架构，在模拟同城两机房网络故障后，发生业务租户无法访问，业务 tps 跌 0 问题，针对此故障场景发生后，如何应急预案。

## 适用版本

OceanBase 数据库 V4.0 之前的版本。

## 背景信息

集群架构：三中心五副本的架构下，同城 A、B 两机房各有 2 个 Zone，第三机房 C 有 1 个 Zone。Primary Zone 设置为“z1,z2,z3,z4;z5”，即 A、B 机房均为主机房。

问题场景：同城 A、B 两机房之间网络不通，但 A、B 分别与第三机房 C 的网络是连通的。

在这个场景下，因为 A、B 机房中均有 Leader 副本，且均能与 C 机房构成多数派。当 A、B 机房网络中断时，不会发生 Leader 改选。而因为 A、B 机房网络中断，不论 RS 在 A 机房还是在 B 机房，均无法感知对方机房的 OBServer 状态，也无法获知对方机房内 Leader 的上任情况。业务也不能实现跨 A、B 机房的访问。因此，在该场景下 OceanBase 数据库无法做到真正的高可用，无法做到业务不中断。

## 应急策略

针对此场景，应急解决办法为：当 A、B 机房不通时，必须让 A、B 机房中的一个机房成为“孤岛”，即让 AC 或 BC 的网络也同时不通，从而让 OceanBase 数据库的高可用机制可以发挥作用，通过切主把“孤岛”机房中的 Leader 副本迁移到另一个机房，从而让集群恢复到可服务状态。

- 选择“孤岛”机房的原则：将 RS Leader 所在的机房作为未来持续提供业务服务的机房，将另一个机房变为“孤岛”。
 - 制造“孤岛”的方法：可以通过网络隔离的方式来将该机房的 OBServer 彻底隔离，或者干脆将该机房的 OBServer 全部杀掉。

由于业务租户是五副本架构，当一个机房被“孤岛”后，剩下的两个机房的 3 个副本要强同步来实现 Paxos 多数派。由于两个机房间的距离较远，网络存在延迟，对业务会有影响，此时还需要将五副本降级为三副本后再继续后续操作。

## 降副本的具体步骤

以下操作以将 z3、z4 剔除为例。

1. 调整 OBServer 机器永久下线时间。

   ```shell
   obclient> alter system set server_permanent_offline_time=60s；

   ```
 2. 确定 z3、z4 的机器上没有分区 leader。

   ```shell
   obclient> select count(*) from __all_virtual_meta_table where role=1 and svr_ip='z3 和 z4 的所有 observer ip'；
   -- 预期返回值应该是 0，表示该 z3 和 z4 所有 observer 机器上没有 leader，所有 leader 都切走。

   ```
 3. 确定所有租户的所有副本都是三副本了。

   ```shell
   obclient> select table_id,partition_id,count(*) from __all_root_table where tenant_id=xx group by table_id,partition_id having count(*)<>3;
   -- 预期返回指为 0，表示租户的副本已经是三副本了。

   ```
 4. 登录 OCP 管理控制台，删除集群所有租户的 z3 和 z4 的所有副本。

   #### 注意

   删除副本一定要批量选择 z3 和 z4，一起同时删除。否则一个一个删除会有问题，导致删除副本操作失败。
 5. OCP 控制台删除集群中 z3、z4 下的 OBServer。
 6. OCP 控制台删除集群的 z3、z4。

## 使用黑屏命令方式对副本数降级的步骤

1. 租户减副本，修改租户的 locality，包括业务租户和 sys 系统租户。

   ```shell
   obclient> alter tenant xxx locality='FULL{1}@zone1, FULL{1}@zone2, FULL{1}@zone3';

   ```
 2. 如果业务租户下有复制表，需要单独对复制表进行副本降级。

   ```shell
   obclient> alter table test_full locality='F,R{all_server}@zone1, F,R{all_server}@zone2, F,R{all_server}@zone3';

   ```
 3. 调整资源池，释放租户在目标 Zone 的资源池，包括业务租户和 sys 租户。如果是每个 Zone 单独的资源池，释放租户在目标 Zone 的资源池时，每次只能释放一个。

   ```shell
   obclient> alter tenant xxxx resource_pool_list=('pool1','pool2');
   obclient> alter tenant xxxx resource_pool_list=('pool1');

   ```
 4. 删除资源池。

   ```shell
   obclient> drop resource pool pool_name;

   ```
 5. 所有租户副本和资源池调整释放后，最后删除 z3、z4 的 OBServer 机器。

   ```shell
   obclient> alter system delete server '192.xxx.x.xx:2882' zone zone3;
   obclient> alter system delete server '192.xxx.x.xx:2882' zone zone4;

   ```
 6. 删除 Zone。

   ```shell
   obclient> alter system stop zone 'zone3';
   obclient> alter system delete zone 'zone3';
   obclient> alter system stop zone 'zone4';
   obclient> alter system delete zone 'zone4';

   ```

   #### 注意

   删除 zone 时，要先 stop zone，只有 inactive 状态下才能 delete zone，否则会报错。

   ```
   ERROR 4633 (HY000): zone status not match

   ```

   并且每次只能一个一个的停止删除 zone，如果停止多个 zone 会报错。

   ```
   ERROR 4660 (HY000): Can not stop server in multiple zones, there are already servers stopped in zone:cannnot stop zone while other stop task is in progress. wait for a moment

   ```

上一篇

[OceanBase 数据库没有生成 core 文件的情况](https://www.oceanbase.com/knowledge-base/oceanbase-database-1000000000761374)

下一篇

[OBServer 故障或者切主后，服务持续受影响时间超 5 分钟](https://www.oceanbase.com/knowledge-base/oceanbase-database-1000000000207687) ![有帮助](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) 咨询热线