kubectl -n tidb-cluster logs 失败pod

业务双写

端口代码写死的，不可能 “飘逸”

若希望 stop log backup task，建一个 “同名” + “logSubcommand: log-stop“ 的 backup https://docs.pingcap.com/zh/tidb-in-kubernetes/stable/backup-to-aws-s3-using-br/#logsubcommand-字段说明

https://docs.pingcap.com/zh/tidb-in-kubernetes/stable/backup-restore-overview/#删除备份的-backup-cr [image]

用 txn_start_ts 的值搜搜看。。。

Succ: false tidb.log 用 txn_start_ts 都下有没有信息

slow log 里的明细看一下

https://docs.pingcap.com/zh/tidb/stable/troubleshoot-lock-conflicts 是否有热数据高并发读写，比如单行热点更新 是否有写慢了影响一致性读

官网文档介绍了功能和性能对比，选哪个看需求

如果是升上来的 operator，CRD 记得也更新下，或者看当前 CRD 里是否是 optional https://docs.pingcap.com/zh/tidb-in-kubernetes/stable/upgrade-tidb-operator

1.5.4 不该有这个问题呀 https://github.com/pingcap/tidb-operator/commit/e03b1b22a7b64010f1bace36bfa788af14b20a53

8.1.2 playground update 大致上会先 select old snapshot data 然后替换 set 值再写回 new shapshot data，这里的特殊情况就是 set 值和 old 值一样的话，会跳过后续流程直接返回成功 如果你做个压力测试会发现，重复 set 相同值的情况下，tidb 压满了 tikv 还很空闲 另外单独的 update where id = ? 估计会走 async commit 乐观事务，可以看下监控 async commit 面板和事务面板

QPS?

长链接？

mysql.user 只是系统表里的其中一张表，比如统计信息、GC 配置等也属于系统表数据，应该是考虑复杂性就统一不同步了 DDL 没同步看下是不是 BDR 的关系， v7.5 BDR 不支持 DDL 同步， v7.6 之后参考文档 https://docs.pingcap.com/zh/tidb/stable/ticdc-bidirectional-replication#ddl-类别 （文档里没提用户相关的 DDL，应该是漏了。。。）