DDL 卡在 cancelling 状态、重启 tidb-server 后 owner 漂移导致这张表所有 DDL 都做不了，是比较棘手的情况。几点：1）先别再重启剩下那台，owner 每次漂移会让状态更乱。用 ADMIN SHOW DDL JOBS 看这个 job（86307）当前的 state 和 schema_state 具体卡在哪一步，以及 ADMIN SHOW DDL 看当前 owner 是谁；2）cancelling 卡死通常是因为该 DDL 已经推进到某个不易回滚的阶段，cancel 请求发出但 owner 在处理时被打断（正好赶上重启漂移），导致状态机停在中间。3）处理思路：确…

78T、多集群 GC 不推进是个典型且要尽快处理的问题——GC 卡住会导致 MVCC 旧版本堆积、TiKV 存储和 CPU 持续上涨、扫描变慢，恶性循环。GC 不推进最常见的原因是存在长时间未结束的事务或未清理的 GC safepoint 阻塞：1）先查阻塞点——SELECT * FROM mysql.tidb WHERE variable_name LIKE ‘%gc%’，看 tikv_gc_safe_point 和 tikv_gc_last_run_time 是否长时间不动；2）查是否有超长事务卡住 safepoint：看 INFORMATION_SCHEMA.CLUSTER_TIDB_T…

根因是 a 字段选择性差 + 高并发，走 TiKV 索引扫描效率低（选择性差索引等于扫大量行），走 TiFlash 又因为每条都要列扫聚合、几十条并发直接把 CPU 打满。100w-300w 这个量级其实不大，几个方向：1）资源隔离优先——用 Resource Control 给这类查询单独建 resource group 并限流（RU 上限），避免它们把 TiFlash/TiKV 打爆影响其他业务，这是最快见效的止血手段；2）既然 a 选择性差，单纯 group by 聚合可以考虑加合适的组合索引让 TiKV 侧能覆盖扫描，或者评估这类聚合能否走 TiFlash 但降低并发（应用侧加并发控制…

从你的 systemd 配置看到关键问题：ExecStart 用了 -store unistore。unistore 是 TiDB 的内嵌测试存储引擎，数据存在本地临时目录、进程重启或机器重启后数据不持久，这基本就是重启后“找不到数据库和数据”的直接原因——它本来就不是用来存生产数据的。也就是说，这套其实是单机 tidb-server 直接跑 unistore，不是标准的 TiDB 集群（没有独立的 PD + TiKV 持久化存储）。数据是否有救，取决于 unistore 的数据目录是否还在、是否被覆盖：如果之前跑的时候有指定持久化路径且没被清，可能还能捞；但 unistore 默认多为临时性…

报错 Table doesn’t exist table_id=24461 说明 TiFlash 侧的元数据和实际表对不上，通常是某个 TiFlash 副本的 schema 同步出了问题（比如表结构变更、region 异常导致部分副本状态不一致）。你担心的“设 0 再设 2 期间走 TiKV 全表扫扛不住”是合理的。几个更平滑的思路：1）先别急着重置全部副本，先确认是不是只有个别 TiFlash 实例有问题：查 INFORMATION_SCHEMA.TIFLASH_REPLICA 看这个表的 AVAILABLE 和 PROGRESS，再到 pd-ctl 看这个表相关 region 在各 TiF…

这是个合理的产品改进建议。目前 EXPLAIN ANALYZE 里 TiFlash 算子确实主要展示行数、耗时和并发，内存维度的展示不如 TiKV/TiDB 侧细。可以到 TiDB 官方 GitHub 提一个 feature request（pingcap/tidb 仓库的 issue），描述清楚场景：希望执行计划里 TiFlash 算子能展示内存使用估算，用于排查 TiFlash 侧的内存压力。作为临时手段，现在可以从 TiFlash 的监控入手：Grafana 的 TiFlash-Summary / TiFlash-Proxy 面板里有内存相关指标，配合日志能大致看出某类 MPP 查询在 …

400 多万数据同集群内表到表迁移，其实不一定非得 dumpling+lightning。几种方案：1）同集群、数据量不大的情况下，最简单是直接 INSERT INTO new_table SELECT * FROM old_table，一条 SQL 搞定，配合新表建好正确的分区定义，数据会按新分区规则落进去。400 万行可以分批 INSERT（按主键范围切几批）避免单个大事务，比如 WHERE id BETWEEN x AND y 循环导。2）如果担心迁移期间旧表还有增量写入，可以先停写或在应用层双写，全量迁完后再对增量做补偿（按 update_time 或自增 id 追增量）。3）你排除 …

RC（Resolve Conflict / 读时解锁）等待突然飙到 10s+，但资源组和负载都不高，这种“毫无预兆的一波”通常不是资源瓶颈，而是遇到了锁或事务冲突需要 resolve lock。常见原因：1）有大事务或长事务在某个时间点提交/回滚，读请求撞上它未清理的锁，需要等待 resolve；2）某个悲观锁事务持锁时间长，其他读要等锁；3）PD 或 TiKV 在那个时间点有 region 调度/split/merge，导致短暂的读等待。排查建议：先看 Grafana 的 TiKV-Details → 相关的 lock/resolve 面板，以及 TiDB → KV Errors 里的 lo…

关键问题在于 --where 里的过滤没有让 dumpling 高效分块。dumpling 默认按主键（或 _tidb_rowid）做区间分块并发导出，你加了 update_time < ‘xxx’ 这种非主键条件后，它没法用 update_time 索引来切分块，只能对全表做区间扫描再逐行判断 where，所以日志里 estimate total rows 显示的是全量 64 亿——这个值是 dumpling 估算的整表行数（用于分块规划），不是你条件命中的行数。这就是慢的根因：等于全表扫 64 亿行去筛你那 689 万。优化方向：1）如果导出目的是按 update_time 归档，考虑用主…

tidb_mem_quota_binding_cache 控制的是 binding 计划缓存的内存上限，默认 64MB。这个值只影响 binding（SQL 绑定）的缓存，不是 SQL 执行内存，所以调大它本身不会直接导致执行阶段 OOM，主要影响是能缓存更多 binding。几点建议：1）生产上除非 binding 数量特别多（成千上万条）导致缓存放不下、频繁淘汰，否则默认 64MB 通常够用，先确认是否真有淘汰再调；2）判断依据看 SHOW GLOBAL BINDINGS 的条数和 binding_cache 的命中/淘汰情况，如果 binding 不多就没必要调大；3）监控问题：你说只能…

找不到这个参数，一般是版本差异导致的：系统变量是随版本引入的，如果 tidb_opt_partial_ordered_index_for_topn 是在某个版本才新增，而你的 8.5.6 分支上还没有该变量，就会查不到。建议先确认几点：1）用 SHOW VARIABLES LIKE ‘tidb_opt%’; 看当前版本实际支持哪些优化器变量，确认拼写和实际存在的名称是否一致；2）核对官方对应版本的系统变量文档，确认该参数是在哪个版本引入、是否被改名或废弃（有些优化器开关在小版本间会调整）；3）如果确实是本版本没有，说明对应的优化行为要么默认已启用、要么由别的参数控制，不需要手动设置。若你是想解…

报错是因为系统没安装 selinux 相关包，setenforce/sed 操作 /etc/selinux/config 时命令或文件不存在，–apply 自动修复这一步就失败了。SELinux 检查本身是为了确认它处于关闭状态，你的系统既然没装 SELinux，等价于已满足要求，这项其实不需要修复。处理方式：1）不要用 --apply 自动修复，先只跑 tiup cluster check ./topology.yaml 看报告，SELinux 这项即使标 Fail 也可忽略；2）如果想让检查通过，手动创建 /etc/selinux/config 并写入 SELINUX=disabled，再…

PITR checkpoint 不推进通常是有大量变更日志未完成扫描。先检查 br log status 的 lag 和进度，确认共享存储权限无变化；v8.5.3 可尝试调整 --concurrency 参数并观察日志中是否有 scan/merge 阶段的报错信息。

这是 Go runtime 的 fatal error，通常由并发 bug 触发（如重复 unlock 或 signal handler 中不当操作）。v7.5.0 已较老，建议升级到该大版本最新 patch，同时检查是否有 goroutine 泄漏导致内存压力触发竞态。

MPP Failed 计数表示查询下推到 TiFlash 执行失败（超时、内存不足、节点异常等），引擎会回退到 TiDB 执行。短时间内少量失败正常，持续飙升需检查 TiFlash 节点资源使用和报错日志。

不建议只替换 TiCDC 版本直接尝试。先确认上游 TiDB 5.4 与目标端 7.1.3 的兼容矩阵，排查大表卡在 scan、sorter 还是 sink；升级前建议测试环境完整验证。

是拆分仓库维护的。源码调试时建议以 release tag 为准，pd、tidb、tikv 都切到同一 TiDB 版本对应的 tag，再结合 go.mod/组件版本确认依赖。

connection refused 说明 184:2379 上没有 PD 进程监听或网络不通。排查：1）新机防火墙/安全组是否放行 2379、2380；2）tiup cluster scale-out 后是否在该机成功 deploy 并 start pd，tiup cluster display 看 184 状态；3）若 184 是已缩容旧节点，scale-out 不应再指向它，检查 scale-out 拓扑是否写错 IP；4）SSH 到 184 看 pd 日志与端口 ss -lntp | grep 2379。先保证单机 pd 能起，再执行 join 已有集群。

TiFlash 副本数受 Region/表数量与元数据开销影响，官方长期建议控制同步表数量（数百级更稳，上千需评估）。新版本会持续优化多表场景，但是否完全「解决」要看具体版本 Release Note，建议查 v8.x TiFlash 容量规划文档。实践上优先对热点分析表按表 REPLICA，整库同步前评估表数与数据量；大库可只给核心宽表加副本，避免无脑全库 TiFlash。