嗯嗯 这个地方确实有个 bug。当 lock stats 之后，如果还开了 tidb_enable_historical_stats 的话，它找已经锁定的表的统计信息的时候回找不到相关的历史。所以有这个问题。可以帮忙在 GitHub 开个 issue 我们修一下。

你 lock stats 的表 id 是 3003 吗？

你第一个是看的哪个表？是 mysql.stats_meta 吗

我看了下你的第一个日志，这里面分析的就是缺分区 P20240501 的表吧？日志里面没看到你分析这个分区的记录。有一些其他的分区。 另外你可以用 P20240501 的物理 id 在 mysql.stats_meta 里面找找看有没有这个分区的记录。 也可以在 mysql.analyze_jobs 里面找一找这个分区相关的记录。看看上次成功是什么时候。

这是每个 ticdc 实例上每个 changefeed 的总额度。 例如：你现在有 4 个 changefeed。 32 个 ticdc server。 那么每个 changefeed 都会分配几张表到每个 server 上。 那么理论上消耗的内存就是： 4 * 32 * 1 G = 128G。但是上面说的这些内存限制都是针对 sink 模块的。你遇到的问题应该是 sroter 模块拉数据和缓存数据到内存造成的。 因为你现在是所有的 ticdc 混布，你需要用 cgroup 正确限制内存资源，否则就会导致 TiCDC 拿 host 的 70% 作为使用额度来在 sorter 模块中…

例如： memory-quota=104857600 暂停 changefeed: cdc cli changefeed pause -c changefeedID 更新 changefeed: cdc cli changefeed update -c changefeedID --sink-uri=“xx” --config=changefeed.toml。注意不要更新到其他不想改的参数了 恢复 changefeed: cdc cli changefeed resume -c changefeedID

就是我上面说的参数，可以通过在 changefeed 中配置 memory-quota=104857600，将每个 changefeed 的总内存限制一下。

你们一台机器配置多少，部署了几个节点啊？

6.5.2 这个参数现在没生效了。不好意思，文档滞后了，我改改。

升级之后 lag 很大吗？

用我上面发的那个参数，changefeed 的配置，不是 server 的配置：memory-quota=xxx。

6.5.2 控制内存的参数是：在 changefeed 的 config 设置 memory-quota=xxx。它的默认值现在是 1G。 你们是几个 changefeed？可以把它调小点。

你的 sink-uri 写错了，传递参数的形式是 xxx?a1=1&a2=2&a3=3

这就很诡异，你能贴下改完之后完成的创建过程和报错日志吗？顺带查询一下你的 topic 的这些参数信息。

你在 sink-uri 里面带上 replication-factor= 3 试试

这个看起来不是很符合预期，你的集群默认的 replication-factor 是多少？你的 changefeed 创建 sink-uri 长什么样？ ticdc 只会在 replication-factor < min.insync.replicas 时报错。等于大于都不会报错。你的 topic 是新建的还是旧的，如果是旧的那么它创建时的 replication-factor 是多少？

我要挑战。

可以采用：https://pingcap.feishu.cn/docs/doccnpPgWuyZu0sPNHtPM7Cg7Kf# 这个手动解决方案来暂时解决这个问题。我们后续的版本会修复这个问题，收到影响的版本在文档中有说明。

这是个已知问题，我们有个 fix 但是漏了一部分代码。https://github.com/pingcap/tiflow/issues/5266#issuecomment-1111711739 我们重新修复一下。谢谢反馈！