# Postmortem: TCOC-5841

> Workspace: `ws-1787286760265-167b90c0a`
> Date: 2026-08-24
> Reviewer: evolver-bot

## Issue Summary

| Field | Value |
|-------|-------|
| Issue ID | TCOC-5841 |
| Alert Type | CDC resolveTs lag > 2 minutes |
| Cluster ID | 10994032495048224297 (keyspace 126719) |
| Cluster Type | essential (shared v2) |
| TiDB Version | Unknown (shared pool) |
| Time Window | 2026-08-20 22:00 CST – ~2026-08-21 |

**Issue Description**: resolveTs 在 22:00 后持续超过 2 分钟，用户报告 changefeed 无法追上，根因是同一 shared pool 上邻居集群的 changefeed 占满了共享 TiCDC replication worker。

## Actual Root Cause

> Human-confirmed root cause from user feedback (issue #1064–1066) and direct user correction in workspace.

同一 shared pool 上的邻居集群存在一个 changefeed，该 changefeed 大量占用了共享的 TiCDC replication worker 资源（slots / 处理队列），导致本集群（keyspace 126719）的 changefeed 任务无法被及时分配 worker，min_resolved_ts 无法推进，resolveTs lag 持续 > 2 分钟。这是 Essential 共享架构下的 noisy-neighbor 问题，TiCDC 层无租户级硬隔离。

## Agent Diagnosis Summary

> Initial unguided diagnosis (assistant texts 1-13) concluded:

Agent 的初始诊断将根因定为：**4 个 TiDB 实例重启 → 孤儿悲观锁积压 → TiKV resolve_lock scheduler 高负载 → TiCDC min_resolved_ts 路径被阻塞**。

证据链较完整（找到了 resolve_lock p99=0.652s、Rollback QPS 3634/s、TiDB 实例重启记录），但未命中真正的瓶颈：TiCDC replication worker 层的 noisy-neighbor 占用。

Agent 的初始诊断排除了下游 sink 错误（正确）、TiKV write stall（正确），但未查询或提到任何 TiCDC 专有指标（`ticdc_processor_resolved_ts_lag`、replication worker 占用率），也未识别 Essential shared 架构下 TiCDC 层的多租户共享特性。

用户在第 4 个用户消息（实际明文更正）后，Agent 立即接受并给出了正确的修正根因。

## Scores

| Dimension | Score (1-5) | Notes |
|-----------|-------------|-------|
| Root Cause Accuracy | 2 | 初始诊断方向错误；识别了相关异常（孤儿锁/resolve_lock），但未命中真正根因（replication worker noisy neighbor）；用户更正后才得出正确结论 |
| Evidence Completeness | 3 | 采集了 metrics、logs、events、component_health；但完全缺失 TiCDC 专有指标（ticdc_processor_resolved_ts_lag、worker 占用率），无法直接观测 CDC 层瓶颈 |
| Causal Chain | 3 | 初始因果链内部自洽（restart → 孤儿锁 → resolve_lock → resolveTs），但链条指向错误根因；修正后因果链清晰正确 |
| Actionability | 3 | 建议中包含扩容、检查 changefeed 状态等，有价值；修正后补充了 noisy-neighbor 处理建议，较具体 |
| Efficiency | 3 | 34 次 tool call，0 次人工干预（用户更正通过 feedback 消息传入，非交互式诊断）；路径发现（工具#2-5 read 尝试）稍有冗余 |
| **Overall** | **2.8** | 初始根因错误是主要扣分项；证据采集框架基本到位但缺 TiCDC 专项 |

## Human Guidance Log

### Intervention 1: 用户更正根因为 noisy neighbor changefeed

- **Round**: #4（user message 4，在 feedback 重复提交后的明文消息）
- **User said**: "The resolveTs long problem was caused by a changefeed in neighbor cluster. It caused the slowness in replication worker."
- **Agent's mistake**: 基于 TiKV resolve_lock 高延迟和 TiDB 实例重启推断根因，未考虑 Essential 共享架构下 TiCDC replication worker 的多租户共享特性；未采集 TiCDC 专有指标
- **Correct behavior**: 应识别 Essential 集群 TiCDC 层为共享资源；在 CDC resolveTs lag 场景应优先查询 TiCDC 侧指标（worker 占用率、processor lag），而非仅从 TiKV/TiDB 视角分析
- **Skill**: `tidb-perf-diagnosis` / `tidb-clinic-diagnosis`
- **Deficiency type**: KNOWLEDGE + TEMPLATE

### Side note: Feedback button submitted 3 times

- 用户在 04:47:23、04:47:36、04:47:56 连续三次通过 feedback 按钮提交了完全相同的内容，三个 GitHub issue（#1064/#1065/#1066）被重复创建。这是 UX 问题，与诊断质量无关。

## Skill Deficiencies

### D1: Essential 集群 CDC 诊断缺少 TiCDC 专有指标采集

- **Type**: TEMPLATE
- **Skill**: `tidb-perf-diagnosis` / `tidb-clinic-diagnosis`
- **Current behavior**: collect_evidence.py 在 CDC resolveTs lag 场景只采集 TiKV metrics（resolve_lock、gRPC）和 TiDB component_health，未采集 TiCDC 侧指标
- **Expected behavior**: 对 CDC 类告警（resolveTs lag、changefeed error），应额外采集 `ticdc_processor_resolved_ts_lag`、`ticdc_replication_task_status`、replication worker 占用率等 TiCDC 专有指标
- **Suggested fix**: 在 collect_evidence.py 中增加 CDC evidence 采集段（A7 or 专项分支），针对 CDC 类告警激活
- **Priority**: P1-high
- **Status**: open

### D2: Essential 共享架构下 noisy-neighbor TiCDC 场景缺少诊断路径

- **Type**: KNOWLEDGE
- **Skill**: `tidb-perf-diagnosis`
- **Current behavior**: Agent 未将 Essential 集群 TiCDC 层视为多租户共享资源，未考虑 noisy-neighbor 场景
- **Expected behavior**: 对 Essential 集群的 CDC 问题，应在排查路径中包含"同一 shared pool 的邻居集群是否有 changefeed 占用 replication worker"这一假设，并在未能找到本集群 TiCDC 瓶颈时提示该可能性
- **Suggested fix**: 在 SKILL.md 的 Essential 集群特殊场景知识库中补充：TiCDC replication worker 为 shared pool 内多集群共享，resolveTs lag 可由 noisy neighbor 触发
- **Priority**: P1-high
- **Status**: open

### D3: Feedback 按钮可在短时间内多次触发（UX）

- **Type**: UX
- **Skill**: `investibook-frontend`
- **Current behavior**: 用户在 33 秒内连续点击 3 次 feedback 按钮，每次都创建新 GitHub issue，产生重复 issue
- **Expected behavior**: Feedback 提交后应禁用按钮（或设置去重窗口 30s），防止重复创建
- **Suggested fix**: 在 feedback onClick 中添加提交后 disable + loading 状态；后端增加幂等检查（相同 workspace + 相同 feedback 内容 30s 内去重）
- **Priority**: P2-medium
- **Status**: open

## Key Queries

### TiCDC processor resolved ts lag (Essential shared cluster)

```bash
# 使用 PSC serverless PromQL 查询 TiCDC 专有指标
# 注意：keyspace 过滤参数需根据集群调整
curl -s "$CLINIC_API/v1/clusters/$CLUSTER_ID/metrics" \
  -H "Authorization: Bearer $CLINIC_TOKEN" \
  -d 'query=ticdc_processor_resolved_ts_lag{keyspace_id="126719"}'
```

### TiCDC replication worker occupancy

```bash
curl -s "$CLINIC_API/v1/clusters/$CLUSTER_ID/metrics" \
  -H "Authorization: Bearer $CLINIC_TOKEN" \
  -d 'query=ticdc_replication_task_status'
```

## Lessons Learned

- Essential 集群 CDC resolveTs lag 不能只从 TiKV/TiDB 视角分析；TiCDC 层是共享资源，noisy-neighbor 是合法的根因假设
- collect_evidence.py 目前没有 TiCDC 专项采集段，导致 CDC 类告警的诊断存在系统性盲区
- Feedback 按钮的重复提交需要在 UI 层和后端层双重防护，避免产生重复 GitHub issue
- 用户更正后 Agent 能快速接受并给出正确机制分析，说明 LLM 推理能力本身没问题，缺的是初始阶段的 TiCDC 知识和采集模板