自己重新编译tidb和插件。

这个是重点，其实相当于把 cargo 的缓存目录指定到了 vendor下面。

祝 TiDB 越来越多人用，成为全球最流行的分布式数据库！ [image]

2025 万事胜意，心想事成

然后，将·cargo vendor 命令打印至【标准输出】的配置代码（如下）·复制到.cargo/config.toml 配置文件内。 [source.crates-io] replace-with = "vendored-sources" [source."https://github.com/shadowsocks/crypto"] git = "https://github.com/shadowsocks/crypto" branch = "master" replace-with = "vendored-sources" [source.vendored-sources] direc…

cargo offline 好像还不是太成熟，我现在的做法是用 cargo vendor 把依赖下载到工程的vendor目录下，然后再编译的时候 export CARGO_HOME=./vendor 就是参考 第二种方案

过去一年看到了 TiDB 新版本中各种奇思妙想，看得出来 TiDB 很努力的在做更好用的数据库，点赞！希望能发扬光大，走向世界！

当然能，因为tikv不知道这个region是index还是普通的region，就是看到的region

你希望活动在哪个城市举办？ 都可以，我线上听听 你希望听到哪些技术主题分享？线上&线下皆可 未来的产品规划 是否愿意成为活动讲师? 否 你所在的城市&你的圈子中，用 TiDB 的企业有哪些？ JD

强大！我就是一开始偷懒了，我感觉冲突肯定是我们的分库分表没把数据弄干净，导致多个库里面有重复数据，想改吧改吧参数忽略了。经猫神一提醒，确实得好好查查！

直接把下游的自增主键改成普通列了。这一列业务实际没用。同步的任务因为冲突暂停了，为了避免从头再来，选择新建别名表，处理好表结构，然后把数据通过 insert into select from 处理。然后重命名，最后再开始同步，可以继续向下走。避免重新load一遍。 insert into aaa select * from bbb; rename table bbb to ccc; rename table aaa to bbb;

经过检查，是分表有自增id作为主键。确实没法继续同步。 看来偷懒是不行的 ，直面问题。

syncers: global: worker-count: 64 batch: 500 compact: true multiple-rows: true safe-mode: true safe-mode 已经是 true 了 我看看为什么冲突吧

写哪儿啊？来个例子？

这个我搜到了，但是我是配置的dm任务，从dm的配置里面怎么改这个？

本来就是一个失败了很久的任务，也没人用，重新启动了下（ts用当前的），发现checkpoint不动。最终是没搞定，直接删了，不同步了，也没时间研究为什么失败了。可惜没法给社区积累经验了

apiVersion: v1 kind: PersistentVolume metadata: name: wordpress-pv spec: capacity: storage: 5Gi volumeMode: Filesystem accessModes: - ReadWriteOnce hostPath: path: /mnt/data 网上找到的pv挂在 hostPath的，你可以参考着把 data 挂载成 pv。

看14小时过去了，是不是已经解决了？ 我们的环境pv都是 csi自动分配的，直接挂载卷的经验不多，给不出直接可用的脚本。 有几点建议： 如果数据很重要，建议优先对data卷做个备份，后面恢复万一失败了还可以重头再来。 按你们的环境建一个pv，然后模拟改一下pv对应的data卷。这一步能成功后再在真实的data上恢复pv pv有了，就好恢复了，pvc关联pv就行，然后对应的启动就行了。

另外我感觉我们讨论的再热闹也没用 ，社区好像没什么人力改版论坛。右上角小铃铛通知加个 “全部已读” 这种事儿得一两年了都没做，那个小红点在那里飘着太难受了。