[TPCC Consistency] ACID violation in TPCC 100W/1000terminals on TKE: D_NEXT_O_ID and w_ytd inconsistent after CN connection disruption

[Ariznawlll]

Summary

main TKE 分布式 nightly 今日 TPCC 100W / 1000 terminals 场景下 ConsistencyCheck 报出 多条 ACID 一致性违反：

1. bmsql_district.D_NEXT_O_ID - 1 = 3147 但 bmsql_oorder 和 bmsql_new_order 在 (w_id=35, d_id=8) 上的 max(o_id) 缺少 o_id=3147（new order 事务原子性违反）
2. bmsql_warehouse.w_ytd 与 SUM(bmsql_district.d_ytd) GROUP BY w_id 不相等，涉及 5 个 warehouse（w_id ∈ {35, 49, 50, 80, 84}）（payment 事务原子性违反）

其它规模场景对比：

场景	参数	ConsistencyCheck
TPCC 10W	warehouses=10, terminals=100	✅ PASS
TPCC 100W	warehouses=100, terminals=1000	❌ FAIL
TPCC 1000W	warehouses=1000, terminals=1000	✅ PASS

100W session 期间发生了 CN 侧大规模连接中断（17:46:23 UTC），随后 consistency 校验失败。

Environment

项目	值
仓库	matrixorigin/matrixone
分支	main
Commit	95f75847 (fix sample function #24324)
集群拓扑	TKE 分布式：3 CN + 1 DN + 3 LogService + 2 Proxy
CN pods 重启情况	CN-czn58: 1 次, CN-s7xmn: 2 次, CN-zph8b: 1 次（DN/Log/Proxy 全程 0 次）
TPCC 客户端直连	profAddr=10.143.206.251,10.143.206.252,10.143.206.250（直连 3 个 CN 的 pod IP，不走 proxy）
触发	Nightly regression
Run	https://github.com/matrixorigin/mo-nightly-regression/actions/runs/25631640632
Job	TPCC BENCHMARK TEST (id=75244799463)

集群拓扑、重启次数来自 CLEAN UP ENV 步骤执行前抓取的 kubectl get pods -o wide 快照。

Failure Evidence

Consistency check failures (TPCC 100W, session: 17:43:33 - 17:48:44 UTC)

在数据库 tpcc_100 上 17:48:45 UTC 校验失败，4 条 SQL：

(1) D_NEXT_O_ID vs bmsql_oorder.max(o_id)

(Select d_w_id, d_id, D_NEXT_O_ID - 1 from bmsql_district)
  except
(select o_w_id, o_d_id, max(o_id) from bmsql_oorder group by o_w_id, o_d_id);
-- Result: (35, 8, 3147)

(2) D_NEXT_O_ID vs bmsql_new_order.max(no_o_id)

(Select d_w_id, d_id, D_NEXT_O_ID - 1 from bmsql_district)
  except
(select no_w_id, no_d_id, max(no_o_id) from bmsql_new_order group by no_w_id, no_d_id);
-- Result: (35, 8, 3147)

District (w_id=35, d_id=8) 的 D_NEXT_O_ID - 1 = 3147，但 oorder 和 new_order 表里该 (w_id, d_id) 下的 max(o_id) 都不等于 3147 → new_order 事务更新了 d_next_o_id 但对应的 oorder / new_order 行缺失。

(3) SUM(d_ytd) vs w_ytd

(select d_w_id, sum(d_ytd) from bmsql_district group by d_w_id)
  except
(Select w_id, w_ytd from bmsql_warehouse);
-- Result:
--   35   4467225.31
--   84  11527603.54
--   49   7405822.12
--   80   2845527.26
--   50   1432309.13

(4) w_ytd vs SUM(d_ytd) — 关键异常：同一 w_id 出现多个 w_ytd 值

(Select w_id, w_ytd from bmsql_warehouse)
  except
(select d_w_id, sum(d_ytd) from bmsql_district group by d_w_id);
-- Result:
--   49  7179155.73
--   49  7404462.03    ← 同一 w_id 两个值
--   50  1430093.68
--   50  1428049.45    ← 同一 w_id 两个值
--   35  4041246.45
--   80  2695550.61
--   80  2842313.41    ← 同一 w_id 两个值
--   84 11527247.88
--   84 11526342.05    ← 同一 w_id 两个值

bmsql_warehouse.w_id 是主键，正常情况下每个 w_id 只有一行。这里反向 except 查询对同一 w_id 返回了两个不同 w_ytd，读路径对同一主键返回了多个 version（疑似 MVCC 可见性或存储层多版本问题）。

TPC-C 规则：只有 TT_PAYMENT 事务会在同一事务中同时 w_ytd += h_amount 和 d_ytd += h_amount。两者增量必须相等 → 破坏原子性。

Timeline (UTC, 2026-05-10)

时间	事件
17:26:34 - 17:31:34	TPCC 10W session 1 → 17:31:35 consistency PASS ✅
17:31:40 - 17:36:40	TPCC 10W session 2 → 17:36:41 consistency PASS ✅
17:36:41 - 17:37:45	replace into tpcc_10.bmsql_stock 循环阶段，出现 Lost connection to MySQL server during query（首次 exit code 1）⚠️
17:37:52 - 17:42:52	TPCC 10W session 3 → consistency PASS ✅
17:43:33	TPCC 100W / 1000 terminals session 开始
17:43:33 - 17:46:21	正常跑，tpmTOTAL ≈ 44000 ~ 46000
17:46:22	jTPCC 整秒无日志输出（客户端 1 Hz 心跳中断，典型 TCP 阻塞/RST 前兆）
17:46:23	第一波 FATAL Communications link failure 爆发，[UNEXPECTED][TT_NEW_ORDER][CONNECTION] 连接 11931/11838/10266 等开始失效
17:46:24	单秒内 930 条同类 FATAL，洪峰
17:46:23 - 17:48:37	断连持续 ~2 分 14 秒，期间 tpmTOTAL 剧烈波动并下降至 ~7000
17:48:37	大量 terminal has re-connected to server, this terminal will continue ← CN 恢复
17:48:44	100W session finished，tpmC=15149.01, tpmE (ErrorCount) = 180.12
17:48:45	Consistency verification FAILED（4 条 SQL, 13 行差异）❌
17:49:29 - 17:54:31	TPCC 1000W / 1000 terminals session → 17:54:33 consistency PASS ✅（但 session 期间 exit code 1）

连接中断量化

• 769 个 unique JDBC 连接被标记为 "not valid"（共 1000 个 terminals）
• 1870 条 FATAL 事务（单个连接失效可能连锁多条）
• 涉及 626 个 unique Term-xxx（62.6% 的 terminals 受影响）
• 所有 FATAL 全是 TT_NEW_ORDER CONNECTION 错（MySQL 协议链路层，不是 SQL payload error）
• 62.6% terminals 受影响 + 3 个 CN 全部重启 → 推断至少 2 个 CN 同时出问题（单 CN 崩只会影响 ~1/3 连接）

Hypothesis

1. CN 大规模连接中断是触发器：17:46:23 同瞬 ~62% terminals 连接被重置，结合 CN pod 重启计数（3 个 CN 全部有重启，s7xmn=2 次），强烈指向 至少 2 个 CN 进程级中断（crash / OOM / livenessProbe）。
2. TPCC 客户端直连 CN pod IP（不走 proxy）：所以 CN 崩立刻把上千连接一起砸掉，现象完全吻合。
3. 中断窗口内 pending 事务的原子性破坏：district 行的 UPDATE 已经被 DN 侧接受，但同事务后续 oorder / new_order 的 INSERT 未执行或未持久化；CN 进程崩溃时未被 rollback。涉及 5 个 warehouse 受影响是点式破坏（非全局），符合"特定事务在特定时刻跨越 commit 边界"。
4. bmsql_warehouse 读路径对同一 PK 返回多个 w_ytd version 的现象需进一步验证，可能是 MVCC tombstone 未 GC 或可见性判定错误。
5. 10W（100 terminals）不触发，100W（1000 terminals）触发 → 高并发 + CN 链路抖动 是必要条件。

Reproducibility

当前仅今日 nightly 一次观测，下次复现需：

• 在测试 workflow 中先保留日志再 CLEAN UP（当前 CLEAN UP ENV 直接 kubectl delete ns，事后 Loki 中的 stream 也随之过期消失，详见 comment）
• 或在测试框架里注入 fault（kubectl delete pod main-nightly-regression-dis-tp-cn-0）观察是否稳定复现

Related

• 同一 run 的性能回归 [Perf Regression] sysbench random_ranges tps -45% after #24309 #24335（sysbench random_ranges -45%，已定位到 PR fix(plan): prevent OOM from non-selective secondary index range scans #24309）
• 1000W session 末尾报 [UNEXPECTED][TT_NEW_ORDER][EXECUTION] ErrorCode : 1062, Duplicate entry '(35,8,3148)' for key '(o_w_id,o_d_id,o_id)' —— 同 warehouse=35 district=8 下，o_id=3148 重复（联系 100W 的 3147 缺失，两者在同一 (w,d) 上）。
• 同 run 其它非性能失败：CONCURRENT Update pk 100 Threads 报 connection reset by peer (10.143.206.252:6003)；SYSBENCH 1000W 在 twin run 中报 context canceled 全线 FATAL —— 表明当日 CN 链路在高并发下普遍不稳定，TPCC consistency 失败可能是同一根因的原子性维度表现。

Priority

P0 — ACID 违反，属核心数据库正确性缺陷。