tiup diag collect <集群名 tiup cluster list 可以看> -f=“2025-10-00 10:30:00 +0800” -t=“2025-10-00 11:00:00 +0800” --include=“monitor,log” 注意 -f “2025-10-00 10:30:00 +0800” 这些时间，改成限额报错前 15 分钟， -t 改成限额报错后 5 分钟 ， 收集完成后 tiup diag upload {收集目录} ， 如果是生产问题可以用先关闭 tiflash rc 绕过。

不要用 tiflash 的面板看，用截图中编辑 ru 面板的表达式把 tp 改成 ap 来看，或者新增一个 ap 来看，是不是当时 ru 耗尽了。

tiflash_wait: {pipeline_queue_wait 高是 rc 的限制。 方案 1 关闭 tiflash 的 rc 功能绕过 rc 的限制。 #添加关闭tiflash RU配置 tiup cluster edit-config tiflash: profiles.default.enable_resource_control: false 查看 olap 的 rc 是不是有瓶颈。 [image] 可以进一步上传 clinic 看看。

如果目标表是空表，使用 import into 语法。 https://docs.pingcap.com/zh/tidb/v8.1/sql-statement-import-into/

Resource Control 现在不能管理 tidb-server，就是 RU 只算 TiKV 的开销。

很有画面感。

用 cdc changefeed query -c changefeed-id，确认 cdc 里面的用户名和 IP ，在 CDC 主机上用 mysql -h IP -P port 确认是可以登录了，确认下游负载均衡等都是好的。 用 cdc changefeed pause/resume -c changefeed-id 恢复，再看一下 cdc.log，具体的日志有什么报错。

我这里复现了这个问题，手工用 lightning tidb 模式导入报错的表仍存在这个报错，分析后是源库中部分行存在乱码字段，怀疑是半个字符导致的，备份的文件中也会把乱码导出，使用 update set col1=substr(col1,1,18) 后修复。 报错 [image] notepad 工具打开报错行整理后 [image] hexdump 的输出 [image] 修复过程 [image]

手工用 dumpling 备份有类似的现象吗？有没有可能是连接时长的防火墙的问题。

用 explain analyze 分别看一下“正确“和”不确认“结果的执行计划。

把 raft 选举和改为在 PD 上的 etcd 选主，各有优势。pd 选主就和 ticdc 一样，高可用架构简单，对成员数量没有要求。raft 选举最小成员要求3个，优势就是和 pd 解耦可以独立，比如可以实现一个更高层次的流量调拨，多个机房的 TICDC 复制链路的上下游可以做访问控制。 权限和多机房的场景都很有现实意义。权重是 LB 的标配功能。用户有多机房的场景，可能需要多 VIP，类似 ticdc 的 cluster-id 功能,及 tidb server label 的位置“感知”，进而和 tikv server label 的 closest-replica 配置就实现流量在…

TiProxy 管理 VIP 能力是线下部署比较期望的一种能力。 不过集成 keepalived 是不是不太好的一个选择，vrrp 协议是不是太重了，新一代的 MySQL 集群管理软件都不太使用 keepalived。用 raft leader 实现一个 VIP 管理能力是不是更好？

#!/bin/bash 执行查询语句，并将结果存储到数组中 result=($(mysql -h tidb-ip -P 4000 -u root -p’’ -N -e “select TIDB_TABLE_ID from information_schema.tables where TABLE_SCHEMA=‘your_schema’”)) 遍历数组 for item in “${result[@]}” do AUTO_ID_CACHE=$(curl -s http://tidb-ip:status-port/schema?table_id=${item} 2>/dev/null…

https://docs.pingcap.com/zh/tidb-in-kubernetes/stable/backup-to-pv-using-br 文档中描述得很清楚，tikv pod 也需要有 NFS 的 volumemounts 。 确认可以从 Kubernetes 集群中访问用于存储备份数据的 NFS 服务器，并且你已经配置了 TiKV 挂载跟备份任务相同的 NFS 共享目录到相同的本地目录。

K8S 环境建议使用 BACKUP CRD 的方式进行备份。

不支持自增跳变。需要改 Auto cache id。 update 带有两次列运算时行为不一致。UPDATE h SET h.lock_qty = h.lock_qty + 3, h.usedable_qty=h.onhand_qty - h.lock_qty // 在mysql中用的是上面h.lock_qty = h.lock_qty + 3后的值, 而在tidb中用的更新前的值 提示的 collation 不支持，比如 mysql 8 默认的 collation utf8mb4_0900_ai_ci。

除了一个会话内相同操作多次，基本上 conn id + job id 可以定位分段的唯一执行。 BTW: K8S 环境的 POD 日志，最好用其他手段持久化一下。

还有看一下，tidb.log 在 duplicate key 报错期间的上下日志。

日志不太全，还是得看一下两个 batch 语句 start a Non-transactional DML做为起始时间 ，最后一个 jobid 做为结束时间 。 admin show ddl jobs 的 truncate 时间 ，看一下各个时间 有没有交叉。