AI 分析： 社区问题 1059034 结论： 根因：离线环境 tiup br 的本地 mirror 元数据过期后尝试联网刷新 → 超时 hang。不是强制要求最新版，是 tiup 的本地缓存机制在离线环境不可靠。 方案：直接用安装包自带 BR 二进制，绕过 tiup： ./br backup db --db test --pd "pd-host:2379" \ --storage "local:///backup/" --check-requirements=false 同版本 BR + 同版本集群无兼容问题，--check-requirements=false 安全可加。 社…

如果服务器的 cpu 内存、io 用的不高。 网络带宽也没有到瓶颈。 那么监控 ping 5ms 算高得了。因为默认 blackbox 的 ping 是一个很小的请求，并且会被 15s 弱化掉。 tidb 读取 跨网络的，网络影响还是比较大的。

社区问题 1057818（v8.5.4 慢 SQL IndexLookUp）根因结论 一、根因（一句话） TiKV coprocessor 在 “tracker 之外” 的调度段（gRPC handler → unified-read-pool 排队 + parse_request + region cache 查询）累计 ~518ms，叠加 gRPC 往返 ~429ms；TiKV 自身计算/锁/snapshot/IO 都不是瓶颈。混部 3 台环境是放大器。 二、铁证三段 gap 拆解 IndexRangeScan_13 cop_task： 段 公式 耗时 性质 gap A…

社区 topic/1057715 分析报告 — Dashboard 日志搜索 CANCELLED 社区问题：dashboard日志搜索所有tikv节点的日志 版本：v8.5.3 | 客户：社区用户 | 现象：Dashboard 日志搜索搜不到 tikv(10.0.1.228:20160) 的日志，PD 报 LogSearchTask stopped with error... rpc error: code = Canceled desc = CANCELLED 1. 问题澄清 Dashboard log search 搜不到特定 TiKV 节点日志，PD 日志同时出现两类告警： L…

社区 topic/1057681 综合分析报告 问题：tidb_mem_quota_binding_cache 生产配置参考、调大隐患、监控方案 版本：v7.5.3 一、参数机制（源码确认） tidb_mem_quota_binding_cache 控制 binding 计划缓存的字节级内存配额，默认 64MB。底层是 kvcache.SimpleLRUCache，条目数无上限，纯按字节触发 LRU 淘汰。通过 memory.Tracker 挂到 TiDB 全局内存树，受 server 总 OOM 管控。 二、核心澄清：调大不会让 SQL 匹配变慢 这是社区最常见的误解。源码确认 bi…

AI 综合分析 最终结论 + 对客回复 核心结论 tikv#18109 已知 bug，TiKV v8.5.4 受影响，目前无 fix。 TiKV 启动 init 阶段调用 block_on(pd_client.get_tso()).expect(...) 获取首次 TSO，该调用无重试机制。底层 tso-worker 线程因 TSO gRPC stream 异常退出后，所有 pending 的 oneshot 通道被 drop，报 “Timestamp channel is dropped” → 直接 FATAL panic。 该问题已被客户独立上报为 tikv#19845（2026-07…

如果是这个问题的话，应该还没有修： [image]

重启还是搞不定么？ 我这边内部 AI 分析了下，历史上遇到的问题可能是 pd 这边有时钟跳转或者当时卡了下。 pd leader 的日志发一下。

辛苦提供下完整的 tikv panic 以及前后日志。 我让 AI 先分析下。 你 br 恢复，br 版本是 v8.5.4 的么？日志也上传一份呗。

tikv 多大的盘，导入了多少数据量 是 SSD 的盘么

@王军 补充判断依据的完整版： 社区问题 topic/1057704 — TiCDC v8.5.5 主备集群同步反复故障 结论 不是 TiCDC 代码 bug。 是下游连接周期性被杀 + TiCDC 连接池缺少主动回收 + changefeed 被外部停止的复合运维问题。 判断依据 依据 1：重试远未耗尽，changefeed 被外部停止 源码 mysql.go:56 定义 DML sink 最大重试 8 次，退避区间 500ms → 60s 指数抖动。 客户 cdc.log（30 条，410 行）： 指标 实际值 自然耗尽应达到 invalid connectio…

cdc 使用最好在 tidb 6.5 最新版本以上。 低于这些版本问题比较多。 你 5 的版本可以考虑用 binlog 过度来迁移升级。

AI 解析： 社区问题分析报告：TiKV LIKE 表达式 Panic 问题链接: tikv 重启后一直 panic 无法稳定 1. 问题定性 TiKV 在 coprocessor 执行下推的 LIKE 表达式时 panic，调用链： impl_like::like (impl_like.rs:50) → Like_Fn::eval → BatchSelectionExecutor::handle_src_result → coprocessor::endpoint::Endpoint::handle_unary_request_impl Panic 原因：range …

没有统一的。 如果只是代码学习可以不用切版本，如果自己想做开发等需要切换对应分支。

AI 分析： 社区帖子 1056938 结论 根因：tiflash#10163（JoinPartition.cpp Arena::alloc 不保证对齐 → aarch64 上 std::mutex 触发 SIGBUS → TiFlash 进程崩溃）。x86 不崩（硬件容忍非对齐），aarch64 必崩。Bug 2023-11 引入，2025-05-19 修复（PR #10175），v8.1.2（2024-12 发布）带 bug、不带修复。 给客户的话术（5 分钟生效）： server_configs: tiflash: profiles: default: join_probe_ca…

使用 源码 agent 核对了下上面内容： @王军 独立跑了 pprof 并核对了源码，@ticket_new 的大方向对（瓶颈在 sorter 读路径，不是下游 sink），但参数名、机制细节、根因定位有 4 处明显偏差。 一、数据/数学核对（ 全对） 项 @ticket_new 实测 核对 总采样 1254.17s / 4158.60% 同 sinkWorker.handleTask cum 548.23s/43.71% 同 其中 FetchByTable 占比 96.78% 530.59/548.23 = 96.78% FetchByTable 总量 …

AI 火焰图分析：cdc.zip 分析完成（cpu.prof + goroutine.txt，采集时间 2026-06-25 16:07 CST）。 CPU Profile 关键数据 指标 值 采集时长 30.16s 总 CPU 采样 1254.17s（4158.60%，约 41 核满载） 总 goroutine 1824 CPU 热点分布（按累计） 路径 累计 CPU 占比 说明 SourceManager.FetchByTable → EventSorter.FetchByTable → pebble.iterTable 717.90s 57.…

AI 问题分析： 从 v7.1.3 升级到 v8.5.3 后，TiCDC 到 TiDB 下游的 changefeed 出现 CPU 持续攀升，这是 v8.x 版本 TiDB sink 的事务编码和冲突校验逻辑变化导致的已知行为。Kafka sink 不受影响是因为它不涉及 TiDB 批量写入校验。 capture tables 归零原因： CPU 耗尽后 TiCDC 节点无法向 Etcd 发送心跳维持 session，capture 被判定失活，其负责的表所有权自动转移到其他节点。进程未崩溃是因为底层 goroutine 仍在运行，只是丧失了调度能力。 建议处理方案： 升级到 v8…

我用我的 loop tidb 问题分析团队分析下你这个问题。晚点给你分析结论。