虽然 GA 了，但 bug 太多不建议现在使用

和 mysql 一样的逻辑，需要先 select 后判断是 insert 还是 update，相比单纯 insert/update cpu 高是正常的

pd leader 切换触发阈值很短 https://docs.pingcap.com/zh/tidb/stable/pd-configuration-file#lease ，实际需要额外加上 leader 退出 & 新 leader 初始化 的时间，也可以试下新版本有没有优化

为啥要用 v2

执行计划不一样，低版本慎用

看 slow query 里

低版本 ngmonitor 有问题会不清理历史数据，建议升级下吧，具体的要搜下 github issue 看下，比如我知道的有一个 conprof consume too much disk space and gc doesn't release disk space. · Issue #120 · pingcap/ng-monitoring · GitHub

换成 csv 试试？

投稿邮箱亮了

支持。

以 v1.5.2 为例，代码逻辑为： 读取 secretName 对应 secret， tidb-operator/pkg/backup/util/util.go at master · pingcap/tidb-operator · GitHub 读取后添加进 env， tidb-operator/pkg/backup/backup/backup_manager.go at v1.5.2 · pingcap/tidb-operator · GitHub 最后统一设置到 pod env， tidb-operator/pkg/backup/backup/backup_manager.go a…

update 没专门 blog，大致是类似这一段描述 [image]

这三个是公开的

hint INL_JOIN

dumpling + lightning , 后面会简化为 sql import

~300T BR full backup restore

报错 connection reset by peer 说明这个连接是没被正常关闭的，这时 tidb 尝试正常从 client 读请求的时候发现连接已经被对方关了。 要么忽略无视，要么检查外部链接和网络。