密码不一致吧。要不配置下互信试试。

先看看是不是region频繁调度，leader是不是频繁迁移

目前看应该就只有使用校验工具定期对比表结构了，下游本身就是STRICT_TRANS_TABLES 模式，看着像是无论如何设置，ticdc建立的会话的时候按照内部的sql_mode来处理，和uri以及下游的sql_mode无关。

是的，而且还在ticdc的会话将sql_mode 改成非严格模式，就导致数据被截断了，没找到不截断直接报错的方式。

[image] 好像在uri设置的sql_mode参数并不生效，后面被ticdc给覆盖了。

下游本身就是严格模式。 在changefeed的config文件里设置严格模式，也没有生效，日志里还是上面的信息。

这个如何强制，好像在changefeed的配置文件里写safe-mode严格模式也没生效吧？

默认就包含严格模式。ticdc好像强制设置会话级的sql_mode了。 [2026/07/30 08:57:15.403 +08:00] [INFO] [helper.go:277] [“sink uri is configured”] [dsn=“my_sync:******@tcp(10.0.40.122:4001)/?interpolateParams=true&multiSt atements=true&allow_auto_random_explicit_insert=1&charset=utf8mb4&foreign_key_checks=0&maxAllowedPacket=…

方案大纲没有问题，影响就是扩容或者设置标签的时候涉及到副本迁移、leader的迁移吧。

换本地的镜像。 另，不是最新版本不会导致失败吧。

我见过开generallog的MySQL库，对系统产生的负载还是可控的。 当然，这个取决于硬件以及业务系统当前的负载。

TiKV没有OOM，如果是TiDB的OOM，那和TiKV关系也不大，要去分析TiDB的OOM的原因，优化SQL。

可以把你的所有的步骤都贴出来，先保证你的部署是成功的。

网络断了吧。

1、PD负责调度、事务全局的时钟分配TSO、region信息的管理； 2、推荐3个是避免单点； 3、PD停止，无法正常读写数据，一是无法获取TSO，二也无法得知region的分布，因此集群就挂了。

那可能针对slb来说连接就是均衡的了。 qps和CPU低，只能说明恰好分配过来的应用连接占用资源的少。