---
title: OB 3.2.4.5 主机替换卡在最后两个副本（源节点磁盘错误导致迁移失败）-OceanBase数据库使用指南
description: 了解OceanBase数据库在实际应用中关于OB 3.2.4.5 主机替换卡在最后两个副本（源节点磁盘错误导致迁移失败）相关的常见问题和使用技巧，帮助您快速解决OB 3.2.4.5 主机替换卡在最后两个副本（源节点磁盘错误导致迁移失败）的难题。
image: https://mdn.alipayobjects.com/huamei_22khvb/afts/img/A*OSPzQ6GUQF4AAAAAQHAAAAgAeiGDAQ/original
---
切换语言

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

划线反馈

# OB 3.2.4.5 主机替换卡在最后两个副本（源节点磁盘错误导致迁移失败）

更新时间：2026-08-25 03:31

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

## 问题现象

4-4-4 架构的集群，在使用 OCP 对 Observer 进行主机替换时，替换流程卡在最后两个副本无法完成。被替换节点为 10.32.29.117，新节点为 10.32.29.118，两个卡住的副本属于不同 table_id：

- 1108307720861315
 - 1108307720861328

具体表现：

1. OCP 上目标节点 117 长时间处于 **deleting** 状态，最后两个副本迁移进度停滞。
 2. 查询 `__all_virtual_sys_task_status` 发现内部正在执行从源节点 10.32.29.106 向目标节点 10.32.29.118 的副本迁移任务，且这两个副本的 Leader 均位于 10.32.29.128。
 3. 查询 `__all_server_event_history` 发现 118 节点持续出现 `gc_candidates` / `cleanup_replica` 事件，相关分区均对应未迁移完成的两个 table_id，原因显示为 `not in leader member list`。
 4. 被替换节点 117 的 observer.log 中出现关键错误：
      - `errcode=-4225`（OB_PARTITION_NOT_EXIST）：fail to get pg guard、get pg key error、fail to get partition
      - `errcode=-4375`：observer has disk error, cannot be migrate src
      - `errcode=-4388`：Unexpected internal error happen

## 问题原因

### 根因分析

1. **源节点磁盘故障**：被替换主机 117 本身存在磁盘异常，这也是触发本次主机替换的直接原因。磁盘损坏导致该节点上部分 Partition Group（PG）对象已无法被存储引擎正常访问。
 2. **迁移任务依赖源节点读取**：OCP 主机替换产生的副本迁移任务需要从源节点（117）读取副本数据并复制到目标节点（118）。当源节点因磁盘错误无法提供分区数据时，迁移任务无法推进。
 3. **系统保护策略阻止清理**：尝试通过 `ALTER SYSTEM DROP REPLICA` 或永久下线（permanent offline）方式清理异常副本均失败。原因是集群中 zone1 的 10.32.29.106 节点同样存在磁盘异常告警；在多节点磁盘异常场景下，系统为避免进一步降低副本可用性，会拒绝执行可能导致副本数减少的运维操作。
 4. **元数据残留**：即使通过 obadmin 强制删除了 117 上的异常副本，`__all_virtual_meta_table` 中仍残留 member_list 信息，需要调整 `replica_safe_remove_time` 后等待垃圾回收完成。

### 技术原理说明

- OceanBase 的副本迁移依赖源节点能够正常读取本地宏块和微块数据。若源节点磁盘出现坏块或 PG 对象损坏，迁移 RPC 会返回 `-4375`/`observer has disk error`，迁移任务进入失败重试循环，表现为 OCP 界面长时间卡顿。
 - `DROP REPLICA` / 永久下线属于"减副本"操作，RootService 在执行前会检查当前副本分布是否满足安全条件。当同 Zone 或同 Region 内存在其他异常节点时，为避免将三副本降级为两副本甚至单副本，相关操作会被拒绝。

## 关键信息

### 关键日志片段

117 节点 observer.log 中持续出现磁盘错误，表明该节点无法作为迁移源：

```plain
[2026-03-19 10:07:13.888193] ERROR issue_dba_error (ob_log.cpp:2322)
[4184919][0][YB420A201D76-00064D4EEACFFEE4-0-0] [lt=13] [dc=0][errcode=-4388]
Unexpected internal error happen, please checkout the internal errcode(
    errcode=-4375,
    file="ob_partition_service_rpc.cpp",
    line_no=2421,
    info="observer has disk error, cannot be migrate src"
)

```

118 节点 observer.log 中出现源分区不存在相关错误：

```plain
[2026-03-19 10:09:01.369357] WDIAG [STORAGE] ob_partition_migrator.cpp:4630
[3851198][][YB420A201D6A-000642C10F4FD5A7-0-0] [lt=19] [dc=0][errcode=-4025]
failed to batch_post_remove_replica_mc_msg(ret=-4025, leader_addr="10.32.29.128:2882", ...)
[2026-03-19 10:09:01.369701] WDIAG [STORAGE] ob_partition_migrator.cpp:4639
failed to wait_change_member_done for remove(ret=-4025, leader_addr="10.32.29.128:2882", ...)

```

### 关键诊断 SQL

查看副本分布及 Leader 位置：

```sql
SELECT svr_ip, svr_port, table_id, partition_idx, partition_cnt, role, status, leader
FROM __all_virtual_clog_stat
WHERE table_id IN (1108307720861315, 1108307720861328);

```

预期结果：异常副本所在节点 role 为 FOLLOWER，Leader 位于其他正常节点（本例为 10.32.29.128）。

查看正在进行的副本迁移任务：

```sql
SELECT start_time, task_type, task_id, svr_ip, svr_port, tenant_id, comment, is_cancel
FROM __all_virtual_sys_task_status;

```

预期结果：存在 single partition migration / group partition migration 任务，状态为 INPROGRESS，源节点为 117 或 106，目标节点为 118。

查看服务器事件历史：

```sql
SELECT gmt_create, svr_ip, svr_port, module, event, name1, value1, name2, value2
FROM __all_server_event_history
WHERE gmt_create > '2026-03-19 00:00:00'
ORDER BY gmt_create DESC;

```

预期结果：目标节点 118 持续出现 `cleanup_replica` / `gc_candidates` 事件，value2 包含 `not in leader member list`。

查看磁盘状态：

```sql
SELECT svr_ip,
       total_size / 1024 / 1024 / 1024 AS total_G,
       free_size / 1024 / 1024 / 1024 AS free_G,
       (total_size - free_size) / 1024 / 1024 / 1024 AS used_G,
       (total_size - free_size) / total_size AS used_percentage
FROM __all_virtual_disk_stat;

```

## 问题的风险及影响

### 业务影响程度

- 中高。虽然本案例中 Leader 已切换至 zone3（10.32.29.128），业务暂无直接读写中断，但集群处于非健康状态，任意再发故障均可能引发服务不可用。

### 系统风险评估

1. **两副本风险**：两个 table_id 在异常副本未清理前实际仅存 2 个有效副本；若 Leader 节点 10.32.29.128 或另一副本节点 10.32.29.106 再发生异常，将导致分区无主，业务受损。
 2. **级联扩散风险**：zone1 的 106 节点同样存在磁盘异常，该节点上 UPAY 租户的 Unit 无法迁出，也存在两副本风险。
 3. **替换流程阻塞**：OCP 主机替换无法闭环完成，目标节点长期处于 deleting 状态，影响后续扩容、缩容及运维操作。

### 是否有数据丢失风险

- 若仅发生磁盘读取错误且 Leader 仍正常同步 clog，通常不会立即丢失数据；但若多副本同时故障或 clog 同步链断裂，存在数据一致性风险。建议通过 OMS 等方式对受影响表做备份后再执行重建。

## 影响租户

Oracle 租户

## 适用版本

- OBServer：3.2.4.5-bp5-hotfix12 及同系列 3.2.x 版本
 - 租户类型：Oracle 租户
 - CPU 架构：ARM

## 解决方法

### 应急处理思路

当主机替换因源节点磁盘错误卡在最后几个副本时，核心思路是：

1. 确认异常副本是否为 FOLLOWER 且 Leader 正常；
 2. 若直接 `DROP REPLICA` / 永久下线被拒绝，优先处理同 Zone 其他磁盘异常节点；
 3. 对受影响表执行 **重建（drop + create）**，使副本重新分布为 3 副本；
 4. 调整 `replica_safe_remove_time` 加速残留元数据回收；
 5. 完成原异常主机替换及补副本。

### 详细操作步骤

#### 步骤 1：确认异常副本角色及 Leader

```sql
SELECT svr_ip, svr_port, table_id, partition_idx, role, status, leader, member_list
FROM __all_virtual_clog_stat
WHERE table_id IN (1108307720861315, 1108307720861328);

```

确认 117 上副本为 FOLLOWER，Leader 位于其他正常节点（如 10.32.29.128）。

#### 步骤 2：尝试标准清理（预期会失败）

```sql
-- 尝试 drop 异常副本
ALTER SYSTEM DROP REPLICA PARTITION_ID '0%0@1108307720861315' SERVER '10.32.29.117:2882';
ALTER SYSTEM DROP REPLICA PARTITION_ID '0%0@1108307720861328' SERVER '10.32.29.117:2882';
-- 或在 OCP 中对 117 执行"永久下线"

```

若失败，检查失败原因是否为 `observer has disk error` 或同 Zone 存在其他异常节点。

#### 步骤 3：通过 OMS 等备份受影响表数据

对 table_id 对应业务表执行数据备份/迁移，确保可恢复。示例表名需根据实际查询结果替换：

```sql
-- 查询 table_id 对应的表名
SELECT tenant_id, table_id, table_name, database_id
FROM __all_virtual_table
WHERE table_id IN (1108307720861314, 1108307720861315, 1108307720861328);

```

#### 步骤 4：重建受影响表

在业务低峰期执行（表名需根据步骤 3 查询结果替换）：

```sql
DROP TABLE <database>.<table>;
CREATE TABLE <database>.<table> AS SELECT * FROM <source>;

```

或通过 OMS 将数据回灌到新表。重建后 RootService 会自动为三副本分布生成新的副本，异常主机 117 上的旧副本信息会变为孤儿副本。

#### 步骤 5：缩短残留副本安全清理时间

```sql
ALTER SYSTEM SET replica_safe_remove_time = '2m';

```

等待一段时间后检查 `__all_virtual_meta_table`，确认 117 上已无残留副本：

```sql
SELECT svr_ip, table_id, partition_id, role, member_list
FROM __all_virtual_meta_table
WHERE svr_ip = '10.32.29.117'
  AND table_id IN (1108307720861315, 1108307720861328);

```

确认无残留后，恢复默认值（通常为 120m，请按集群原配置调整）：

```sql
ALTER SYSTEM SET replica_safe_remove_time = '120m';

```

#### 步骤 6：处理同 Zone 其他磁盘异常节点

本例中 zone1 的 10.32.29.106 节点也存在磁盘异常，需同样进行替换。待 117 状态正常后：

1. 在 OCP 中对 106 执行主机替换；
 2. 等待副本自动补齐，确认三副本恢复。

### 操作风险评估

- 重建表会短暂影响该表读写，需提前与业务沟通并在低峰期执行。
 - `replica_safe_remove_time` 缩短后，若集群存在其他异常，可能加速孤儿副本清理，需密切监控。
 - 操作期间避免同时触发合并、转储或大规模 DDL，防止 RootService 负载过高。

## 规避方式

### 预防措施

1. **加强磁盘健康监控**：对 Observer 节点磁盘 SMART 信息、I/O 错误率、文件系统只读事件进行持续监控，发现坏盘及时替换。
 2. **避免多节点同时异常**：同一 Zone 内若已存在磁盘异常节点，应尽快处理，避免在集群未恢复三副本前再对另一节点执行减副本操作。
 3. **合理设置告警**：对 `__all_virtual_disk_stat` 磁盘使用率、OCP "磁盘错误" 类告警设置较高优先级，确保及时处理。

### 最佳实践推荐

1. 执行 OCP 主机替换前，先检查被替换节点及同 Zone 其他节点磁盘状态，确认无其他磁盘告警。
 2. 替换过程中持续关注 `__all_virtual_clog_stat`、`__all_virtual_sys_task_status`、`__all_server_event_history` 三个视图。
 3. 对于磁盘已损坏的节点，若无法通过正常 `DROP REPLICA` 清理，优先考虑业务侧表重建方式恢复三副本，而非强制 obadmin 删除，避免元数据不一致。

## 附录：相关错误码速查

| 错误码 | 含义 | 场景 |
| --- | --- | --- |
| -4225 | OB_PARTITION_NOT_EXIST | 存储引擎中找不到对应 PG，常见于源节点分区损坏 |
| -4375 | observer has disk error, cannot be migrate src | 源节点磁盘错误，无法作为迁移源 |
| -4388 | Unexpected internal error happen | 内部异常封装，需查看内部 errcode |
| -4025 | OB_ELECTION_ERROR / 变更成员超时 | 迁移过程中成员变更失败 |

上一篇

[OceanBase 产品版本生命周期](https://www.oceanbase.com/knowledge-base/oceanbase-database-1000000001497334)

下一篇

[4.3.5.3 升级至 4.4.2 后查询 all_tab_columns 系统视图结果顺序不一致](https://www.oceanbase.com/knowledge-base/oceanbase-database-1000000006871397) ![有帮助](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) 咨询热线