环境
OceanBase CE：4.2.1.8
三节点 OBServer：
- 10.205.2.133：zone1，目前服务器损坏，无法启动
- 10.205.2.134：zone2
- 10.205.2.136：zone3
OBD 部署节点：10.205.2.135
OBServer 配置：
- mysql_port：2881
- rpc_port：2882
- home_path：/root/oceanbase
- data_dir：/data/1
- redo_dir：/data/log1
- log_disk_size：2048GB
故障背景
之前服务器发生异常断电，之后多台服务器因文件系统损坏无法正常启动。
对 XFS 文件系统进行了修复后，操作系统可以正常启动，但 OceanBase OBServer 无法启动。
10.205.2.133 当前服务器本身仍无法正常使用。
10.205.2.134 和 10.205.2.136 操作系统均已恢复，但启动 observer 后立即退出，2881/2882 不监听。
核心报错
OBServer 启动时，在初始化 CLOG log_pool 阶段失败：
check_log_pool_whehter_is_integrity_ failed, unexpected error
同时出现：
do_load_ failed(ret=-4016)
log block mgr init failed(ret=-4016, ret="OB_ERR_UNEXPECTED")
init io failed(ret=-4016)
最终：
observer init fail(ret=-4016)
以及：
observer start process failure(msg="observer init() has failure", ret=-4016, ret="OB_ERR_UNEXPECTED")
136 节点也出现 observer 启动失败，并进入停止/销毁流程。
当前 log_pool 状态
134 节点：
/data/1/clog -> /data/log1/clog
log_pool：
/data/log1/clog/log_pool
日志中显示：
curr_total_size=2199023255552
next_total_size=2199023255552
min_block_id=51728
max_block_id=83671
has_allocated_block_cnt=826
实际 log_pool 中数字文件数量：
31943
文件范围实际观察到：
51728 ... 83670
每个文件大小为：
64MB
目录本身没有发现 lost+found、异常软链接或其它明显杂文件。
一个值得关注的现象
发现：
/data/log1/clog/log_pool/51728
和：
/data/log1/clog/tenant_1/1/log/2777
是同一个 inode：
30065164313
硬链接数为：
2
即：
log_pool/51728
与：
tenant_1/1/log/2777
指向同一个物理文件。
目前没有手工删除、修改或重建任何 CLOG 数据。
曾临时将 log_pool/51728 移出目录进行只读分析，但没有启动 observer，随后已经原样移动回来，目前两个目录项仍保持同一 inode，现场已恢复原状。
初步判断
目前可以确定：
OBServer 启动失败的直接原因是 CLOG log_pool 完整性检查失败，而不是普通的 133 节点离线或 Paxos 无法选主。
结合此前服务器异常断电、XFS 文件系统损坏并进行过文件系统修复的背景，高度怀疑：
文件系统故障/修复后，OceanBase CLOG log_pool 的文件、硬链接或日志块分配状态出现不一致，导致 ObServerLogBlockMgr::check_log_pool_whehter_is_integrity_() 校验失败。
但目前无法确认具体是哪一个 CLOG block 损坏，因此没有手工删除或修改 clog 文件。
希望官方协助确认
希望协助确认以下问题：
- OceanBase 4.2.1.8 中
check_log_pool_whehter_is_integrity_()的具体校验条件是什么？ - 当前
min_block_id=51728 / max_block_id=83671 / has_allocated_block_cnt=826的状态具体是哪项不满足完整性检查？ -
log_pool/51728与tenant_1/1/log/2777共用同一 inode、links=2 是否属于正常的 OceanBase log_pool 分配机制？ - 异常断电及 XFS repair 后，是否可能造成 log_pool/block hard link 状态不一致？
- 133 已不可用、134/136 均无法启动的情况下，是否有官方工具可以修复/重建 log_pool 元数据，而不破坏 tenant 数据？
- 是否存在只修复 log_pool/CLOG 元数据、保留 SSTable 和业务数据的官方恢复方案？
- 目前不希望执行 redeploy、destroy 或手动删除 CLOG，希望官方给出数据安全优先的恢复步骤。