wanggx commented on issue #69816:
URL: https://github.com/apache/doris/issues/69816#issuecomment-6490838920
## 更新：定位到更深根因——cumulative point 分裂导致 compaction 卡死
继续排查后，找到了 BE-A 索引能持续重建、BE-B/C 索引停滞的更深层根因：**3 副本的 cumulative point
不同，导致重启后只有低 point 的副本能继续 compaction**。
通过 BE HTTP API `GET /api/compaction/show?tablet_id=xxx` 查看 3 副本的 cumulative
point 和 rowset 版本：
| BE | cumulative point | rowset 版本范围 | compaction 能否继续 | 索引状态 |
| --- | --- | --- | --- | --- |
| BE-A | **3** | [0-1][2-2][3-3]...[20-20] (21 rowsets) | ✅ cumulative
有候选（version>3），持续 compaction + build 索引 | 新 |
| BE-B | **22** | [0-3][4-4]...[13-13] (14 rowsets) | ❌ `candidate_rowsets
is empty`（数据只到 14 < 22） | 旧 |
| BE-C | **22** | [0-3][4-4][6-8]... (12 rowsets) | ❌ 同 BE-B，卡死 | 旧 |
**机制**：
- cumulative compaction 只合并 version > cumulative point 的 rowset。
- BE-A 的 cumulative point=3，数据到 version 21，有 18 个版本可合并 → 持续 compaction，每次合并都
`ann_index_writer` 重建 HNSW 索引 → 索引保持最新。
- BE-B/C 的 cumulative point=22，但数据只到 version 14/12 < 22 → 无候选 rowset →
`candidate_rowsets is empty` → cumulative compaction 卡死。base compaction
也卡（`_input_rowsets.size() is 1`）。
- cumulative point 由 base compaction 推进。重启前 BE-B/C 做过一次 base compaction 把
point 推到 22，之后无新数据写入；BE-A 没做那次 base compaction，point 停在 3。重启后这个差异锁死：低 point 的
BE-A 能继续，高 point 的 BE-B/C 永久卡住。
**这解释了之前两个现象**：
1. 为什么 `BUILD INDEX` 修复无效——它只 build 新 rowset 的索引，不修 cumulative point，BE-B/C
仍无候选，新 rowset 也没有。
2. 为什么 `full compaction` 能修复——它绕过 cumulative/base 分层，强制合并所有 rowset + 重置
cumulative point + 重建索引。
**可观测性补充**：`SHOW PROC '/dbs/{db}/{tbl}/partitions/{part}/{idx}/{tablet}'`
下钻到 tablet 层能看到 `VisibleVersionCount`/`VersionCount`（三副本 12/14/21 不一致），是
compaction/索引落后的信号——但需下钻 5 层路径，不直观，且 `ADMIN SHOW REPLICA STATUS`（最常用）只显示数据
Version（都 21），看不到这个差异。
**修复进展**：对 BE-B/C 触发 `POST /api/compaction/run`
(`compact_type=full&force=true`)，两个副本都开始 `ann_index_writer` 重建 HNSW 索引（每 ~3.5
分钟一个 segment），50GB 索引预计 30-50 分钟完成。修复后验证负载是否分摊到 3 BE。
**给社区的建议补充**：这个 cumulative point 分裂是 compaction 状态机的问题——3 副本重启后 cumulative
point 不同步会导致部分副本 compaction 永久卡死（无候选），进而索引停滞。建议 tablet scheduler 识别 cumulative
point 异常（数据 version < cumulative point 且无候选）并自动触发 full compaction 或重置
cumulative point，而非静默卡死。
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
