Failed值是衡量 TiFlash MPP 引擎稳定性和查询健康度的重要指标。 如果该数值持续升高，说明 MPP 查询在执行过程中遇到了较多的阻碍或错误，需要结合具体的错误日志进行排查

跟着大家学习，部署中的各种情况。

自定义 shell 启动脚本未透传 SIGTERM（无trap转发），会造成 tidb-server 收到双重终止信号； 激进就绪探针（10s 探测周期、3 次失败即杀容器）会持续高频下发 SIGTERM，大幅提升并发信号竞争概率； Burstable QoS 容器 CPU 调度抢占，goroutine 时序抖动，更容易复现锁非法释放 panicTiDB。 这也是该 Bug 在 K8s 部署场景远高于物理机 / 虚拟机 TiUP 部署的核心原因。

TiDB 官方明确：日志备份（Log Backup）不支持 Windows 局域网 SMB/NFS 共享文件系统作为存储后端，生产推荐对象存储 S3/GCS/Azure Blob，本地存储仅支持 Linux 本地 EXT4/XFS SSD 磁盘。 文件锁、原子写机制缺失 TiKV 多节点并发写备份元文件（global_checkpoint、.meta分片文件）时，SMB/NTFS 共享没有 Linux 原生文件锁，出现文件覆盖、元数据写入失败：TiKV 本地生成了新日志段，但无法成功更新存储上的 checkpoint 元文件，本地 TS 无法同步至全局，全局 Checkpoint 卡死。 缓…

维度 评估 能否解决大表同步不推进 大概率能解决，大事务拆分为核心改进 版本兼容性风险 中等风险，跨大版本需谨慎测试 推荐升级版本 建议直接上 v6.5.10+，不要用 v6.5.0 初始版 升级复杂度 中等，需要重建 changefeed、重新测试 业务影响 需评估事务原子性丢失的影响

可以试试，有问题再说

你操作的步骤是怎么样的？缩容后，接着重启集群了？

这么久了还没关， 估计还是没合适的处理办法

TiFlash 副本数默认最小为 1，你设置 TiFlash 副本数 = 1，刚好满足只在高配节点存 1 份副本； 低配 TiFlash 节点保留正常运行状态：接收 MPP 下推计算、分担查询压力，但不会被 PD 调度分配任何 TiFlash 数据副本； 标签调度是 TiDB 官方原生能力，支持库、表粒度精细化约束，兼容所有稳定版本（v5.4 ~ v8.x）

扩容后 Region 不迁移，本质是 PD 调度决策层面出了问题。 要么它认为"已经均衡"（Store 打分机制） 要么被"规则约束"卡住（label/limit/空间） 要么调度器本身就没开。 扩容慢则是 PD 调度执行层面的问题——operator 生成速度受 limit 限制，数据传输速度受 Snapshot 并发数和网络限制。 诊断的起点永远是 pd-ctl scheduler show + pd-ctl operator show all + pd-ctl store --jq 三条命令。 扩容时 TiDB 各模块是如何协同工作的 下面以新增一个 TiKV 节点（sto…

不错不错， 不能在官网主页搞个入口吗

BR 全量初始化 + TiCDC 增量同步 + 灰度切读 + 短窗口切写，业务仅修改连接地址，零代码侵入、数据强一致、运维成熟；

推荐【单写旧集群 + TiCDC 单向同步至新集群 + 业务只读灰度 + 停机短窗口切主】，不推荐无业务改造的全量两地双写 TiDB

扩容 tiup控制机已有相关组件缓存文件。直接分发到目标主机上。 是这个意思吗

需要联网 放开443. 外部访问： ◦ 仅开放 4000：供业务应用/客户端连接 TiDB。 ◦ 仅开放 3000：供运维访问 Grafana（建议再加反向代理或 VPN）。 ◦ 严禁将 2379 直接暴露到外网：官方文档明确警告，该端口承载 PD 特权接口（如 http://IP:2379/pd/api/v1/members），无需认证即可进行敏感操作。 通过反向代理 （如 Nginx）将 /dashboard 路径代理到独立端口，只暴露 Dashboard 路径。 根据官网文档上介绍，集群内部组件间通信的最少端口（所有节点间需互通）

tikv-client.copr-req-timeout 有没有配置这个？

流程理解： TiDB 向 TiKV 发送 Coprocessor 请求（如扫描 RESULT 表索引或执行子查询） TiKV 开始处理（可能耗时几十秒到几百秒） TiDB 阻塞等待 TiKV 返回 在 TiDB 等待期间，MAX_EXECUTION_TIME 的定时检查 无法触发 直到 TiKV 返回数据（或 gRPC 底层超时），TiDB 才有机会检查总执行时间 如果 TiKV 响应极慢，总执行时间就会远超 MAX_EXECUTION_TIME(60000) 建议解决办法：优化 SQL 和索引，减少 TiKV 层的工作量 ，同时结合 Resource…

标准化的工作

业务执行 WHERE 字符串字段 LIKE 'xxx' 模糊查询 TiDB 优化器把过滤逻辑下推到 TiKV，用批量向量化引擎提升查询性能 TiKV 在执行 LIKE 模式匹配时，内部预分配 64 字节固定缓冲区处理字符串 遇到特殊字符串（超长、多字节中文、异常转义符、脏编码数据），代码计算出的截取结束位置是 66，超过缓冲区最大长度 64 触发切片越界 → Rust 抛出 panic → TiKV 进程直接退出崩溃重启 所属 Region 刚刚切为 Follower，查询调度到该 TiKV 节点，刚好复现该 BUG 建议：临时关闭向量化引擎，是否会复现，验证bug 升级修复后的版本