可以建一个 t1 (newHouseUuid,deleted )的联合索引试试看

不保证完全顺序，但是在有可能冲突的情况下会保证顺序，具体可以参考这里：https://docs.pingcap.com/zh/tidb/stable/dm-dml-replication-logic#causality 提供下dm 完整的配置文件看下吧

新版本增加了对登陆密码进行非对称加密的的步骤。 token 的获取可以参考登录界面的登录流程： 通过 api 获取 /api/user/login_info 获取公钥等信息 通过 api /api/user/login 进行登录，payload 为 username 和 password，如果第一步存在公钥，则需要使用公钥对 password 进行加密 参考代码：

alter table xxx AUTO_INCREMENT xxx； 不太推荐这么搞，这个是要每个表去设置的，而且你要基于每个表当前的 _tidb_rowid 最大值去设一个更大的值。 另外， 是重启 tidb-server ，不是重启kv

没理解你要问什么。。。 就是 _tidb_rowid 重复了呀

原理是这样的： 你程序执行的时候已经尝试过这个冲突的 _tidb_rowid 了，所以下一次执行就会采用下一个 _tidb_rowid 举个例子来说： 假如 _tidb_rowid 为10 的 这条数据已经存在， 那么你程序第一次执行的时候会尝试插入 _tidb_rowid 10，然后失败了，这个时候你再手动执行，就会尝试插入_tidb_rowid 11 的数据，然后就成功了。 你也可以通过插入成功的那条数据倒查一下 _tidb_rowid 验证一下，是不是和前面冲突的 _tidb_rowid 不一致

你先按上面的这个sql查下这个 rowid 是否已经被占用了 最简单的解决办法是先滚动重启一下 tidb-server ，让缓存的 _tidb_rowid 往前刷一下，大概率能解决问题 如果还是解决不了，那就只能每个表手动设置一下了。

非聚簇表的主键是按 _tidb_rowid 可以按照这条 sql 查下哪条数据冲突： select _tidb_rowid , change_records.* from change_records where _tidb_rowid= 81432804; 可能是由于 lightning 导入异常导致 rowid 被异常占用了

1. 关于这个报错 v1.5.2 的 operator 相关逻辑做了一些修改 v1.5.2 是真实大小, v1.4.0 是最小的大小： v1.5.2 Status.Capacity：Represents the actual resources of the underlying volume. [图片] v1.4.0 Spec.Resources: Resources represents the minimum resources the volume should have. [图片] 2.当前报错原因为 PVC 申请的 300g 和 local pv 实际大小 35…

可以同步下解决方案， 并标记为最佳答案哦

ddl owner 对应的 tidb 节点有什么异常日志吗？

一个是 proxy.proxy-protocol 对应sql端口的配置 另一个是 api.proxy-protocol 对应 http 网关的配置。

对业务有实际影响吗？ 如果 backoff 时间不是很长，这种可以忽略的

集群 整体 qps 是多少？ 99 ， 80 duration 有波动吗？

用户业务行为发起的 sql 统一被划分到 general ，与之对应的是 internal 就是集群本身自动执行的内部 sql

不是视图，我试了下 尝试analyze 视图会报这个错： [image]

表结构发下呢

meta 文件没改吧？ 参考这个链接操作下： 专栏 - 机房搬迁更改集群IP | TiDB 社区