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

问题现象

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 中持续出现磁盘错误，表明该节点无法作为迁移源：

[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 中出现源分区不存在相关错误：

[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 位置：

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）。

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

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。

查看服务器事件历史：

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。

查看磁盘状态：

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

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：尝试标准清理（预期会失败）

-- 尝试 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 对应业务表执行数据备份/迁移，确保可恢复。示例表名需根据实际查询结果替换：

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

步骤 4：重建受影响表

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

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

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

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

ALTER SYSTEM SET replica_safe_remove_time = '2m';

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

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，请按集群原配置调整）：

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 删除，避免元数据不一致。

附录：相关错误码速查