上游tidb 读写量很大的时候，ticdc任务卡住了，必须重启才能恢复

lxzkenney · 2022 年1 月 11 日 08:57

ticdc 版本 5.0.1

链路： tidb->ticdc->kafka–>es
每个月的月初都会洗大批数据，ticdc的任务都会hang主，我先暂停，然后恢复任务，等一会儿就又开始继续同步了。是否有优化的空间，可以确定的是肯定跟变更的数据量有关系。
怎么排查解决这个问题？

QPS中的INSERT/UPDATE 大概7万多。
一批次更新或者插入 100-500之间

从cdc的日志中发现一段ERROR:
[2022/01/11 19:07:24.127 +08:00] [INFO] [client.go:935] [“EventFeed disconnected”] [regionID=2335235] [requestID=1198541] [span=“[6d44444c4a6f6241ff64ff644964784c69ff7374ff00000000 00ff000000f700000000ff0000006c00000000fb, 6d44444c4a6f6241ff64ff644964784c69ff7374ff0000000000ff000000f700000000ff0000006d00000000fb)”] [checkpoint=430414033444929542] [error=“[CDC :ErrEventFeedEventError]not_leader:<region_id:2335235 leader:<id:10826532 store_id:2 > > “]
1114651 [2022/01/11 19:07:24.127 +08:00] [INFO] [client.go:952] [“EventFeed retry rate limited”] [delay=199.166783ms] [regionID=2335235]
1114652 [2022/01/11 19:07:24.215 +08:00] [ERROR] [client.go:433] [“check tikv version failed”] [error=”[CDC:ErrGetAllStoresFailed]rpc error: code = Canceled desc = context canceled”] [erro rVerbose=“[CDC:ErrGetAllStoresFailed]rpc error: code = Canceled desc = context canceled
github.com/pingcap/errors.AddStack
\tgithub.com/pingcap/errors@v0.11.5-0.20201126102027-b0 a155152ca3/errors.go:174
github.com/pingcap/errors.(*Error).GenWithStackByCause
\tgithub.com/pingcap/errors@v0.11.5-0.20201126102027-b0a155152ca3/normalize.go:279
github.com/pin gcap/ticdc/pkg/errors.WrapError
\tgithub.com/pingcap/ticdc@/pkg/errors/helper.go:28
github.com/pingcap/ticdc/pkg/version.CheckStoreVersion
\tgithub.com/pingcap/ticdc@/pkg/versio n/check.go:128
github.com/pingcap/ticdc/cdc/kv.(*CDCClient).newStream.func1
\tgithub.com/pingcap/ticdc@/cdc/kv/client.go:427
github.com/pingcap/ticdc/pkg/retry.Run.func1
\tgith ub.com/pingcap/ticdc@/pkg/retry/retry.go:32
github.com/cenkalti/backoff.RetryNotify
\tgithub.com/cenkalti/backoff@v2.2.1+incompatible/retry.go:37
github.com/cenkalti/backoff.Ret ry
\tgithub.com/cenkalti/backoff@v2.2.1+incompatible/retry.go:24
github.com/pingcap/ticdc/pkg/retry.Run
\tgithub.com/pingcap/ticdc@/pkg/retry/retry.go:31
github.com/pingcap/tic dc/cdc/kv.(*CDCClient).newStream
\tgithub.com/pingcap/ticdc@/cdc/kv/client.go:421
github.com/pingcap/ticdc/cdc/kv.(*eventFeedSession).dispatchRequest
\tgithub.com/pingcap/ticdc@ /cdc/kv/client.go:788
github.com/pingcap/ticdc/cdc/kv.(*eventFeedSession).eventFeed.func1
\tgithub.com/pingcap/ticdc@/cdc/kv/client.go:575
golang.org/x/sync/errgroup.(*Group).Go .func1
\tgolang.org/x/sync@v0.0.0-20201020160332-67f06af15bc9/errgroup/errgroup.go:57
runtime.goexit
\truntime/asm_amd64.s:1357”] [storeID=3]
1114653 [2022/01/11 19:07:24.215 +08:00] [WARN] [client.go:791] [“get grpc stream client failed”] [regionID=5515474] [requestID=1198537] [storeID=3] [error=“[CDC:ErrGetAllStoresFailed]rpc error: code = Canceled desc = context canceled”]
1114654 [2022/01/11 19:07:24.215 +08:00] [INFO] [region_cache.go:601] [“mark store’s regions need be refill”] [store=10.1.13.7:20160]

从监控图上看到：CDC endpoint cpu线程 100% ，不清楚这个线程是什么意思。

其中一个tikv节点，还挂了一次。

Meditator · 2022 年1 月 12 日 08:03

1、具体到某个表上能有多少？可以估算出来吗？
2、cdc changefeed是怎么配置的？所有库下的表配置在一个任务中吗？
3、changefeed相关的排序规则是怎么配置的？
4、看下grafana相关指标，看看主要是哪个流程是瓶颈，否是可以调整参数解决？
5、看报错日志，并不全是cdc的问题，7w的TPS，可能有热点，上游tidb在不断的分裂和均衡，region leader发生切换导致的

lxzkenney · 2022 年1 月 12 日 09:34

1、具体到某个表上能有多少？可以估算出来吗？
每月初跑任务5亿条数据，固定写入到9张月表中，最大的表8000W。剩下大部分都是3000w-5000w之间。

2、cdc changefeed是怎么配置的？所有库下的表配置在一个任务中吗？
5个任务，按库过滤的，以库为单位，每个库一个任务。不过90%的数据都是在其中一个库中。

3、changefeed相关的排序规则是怎么配置的？
“sort-engine”: “unified”

4、看下grafana相关指标，看看主要是哪个流程是瓶颈，否是可以调整参数解决？
从监控看cdc 机器的cpu 在75%左右。我们机器配置是 96和 384G的。
都是独立部署的。 cdc 吃CPU挺厉害。

5、看报错日志，并不全是cdc的问题，7w的TPS，可能有热点，上游tidb在不断的分裂和均衡，region leader发生切换导致的

Meditator · 2022 年1 月 13 日 06:28

可以把出问题的时间段内grafana的cdc这块的指标数据导出一份，谢谢。
具体参考：
https://metricstool.pingcap.com/#backup-with-dev-tools

lxzkenney · 2022 年1 月 13 日 06:38

tidb-financial-app-TiCDC_2022-01-13T06_36_16.941Z.json (15.6 MB)

已上传，辛苦，帮忙看一下~

Meditator · 2022 年1 月 13 日 08:08

目前看是cdc的连接tikv的时候超时导致的，但是此时cdc还是正常可以工作的，只是连接tikv时报错。这个可能要排查上游tikv的负载情况，或者看看tikv的日志有什么异常？

Meditator · 2022 年1 月 13 日 09:09

看到这里，突然想起来一个事情，cdc集群同步表的个数好像有限制，4.x的上限是2k个，这里每个capture负责1.64K个，超过上限。这个需要研发的大佬确认下。

lxzkenney · 2022 年1 月 13 日 09:38

我们现在用的ticdc 版本 5.0.1，不知道是否也超限了。

lxzkenney · 2022 年1 月 13 日 10:01

tikv_20220111.gz (21.8 MB) [tikv_20220111.tidb-financial-app-Overview_2022-01-13T09_57_11.425Z.json (6.2 MB)
tikv监控和 tikv节点日志。
确实有一台挂了。这是挂掉那台的日志。

Meditator · 2022 年1 月 13 日 10:14

1）实际上，cdc监听了上游tidb中多个表？
2）这里sorter排序用到了磁盘，请问磁盘是什么类型的盘？

3）排序方式为unified，默认优先使用内存，超过内存限制（2个指标：内存分配默认 16G、当前系统可用内存百分比），或者下游写入慢，触发流控，都会触发磁盘缓存，有没有用到磁盘缓存，可以看 ticdc 监控项 Unified Sorter-Unified Sorter on disk data size
参考这里 ticdc unified sorter 几个疑问 - #5，来自信仰在空中飘扬
建议cdc 内存配置比例高一些。

Meditator · 2022 年1 月 13 日 10:17

cdc需要优化，tikv也需要监控，不要挂掉，否则必然对cdc 有影响。

lxzkenney · 2022 年1 月 14 日 09:30

tikv13.log.gz (20.0 MB) cdc-2022-01-13T22-40-16.520.log.gz (22.4 MB)

故障时间点的日志，和监控图。 TIKV oom了。我把storage.block-cache.capacity75G 调整到50G了。一台机器96C/384G 部署了两个TIKV节点。
机器配置：腾讯云高IO型黑石物理服务器BMI5 ，本地NVMe SSD盘，两块。对应俩TIKV节点。

lxzkenney · 2022 年1 月 14 日 09:34

我们的是 tidb 5.0.1版本，对于下边这个，调整内存，我看官方说新版本变了，不支持配置了。 cdc 可配置的参数貌似很少。

3）排序方式为unified，默认优先使用内存，超过内存限制（2个指标：内存分配默认 16G、当前系统可用内存百分比），或者下游写入慢，触发流控，都会触发磁盘缓存，有没有用到磁盘缓存，可以看 ticdc 监控项 Unified Sorter-Unified Sorter on disk data size
参考这里 ticdc unified sorter 几个疑问
建议cdc 内存配置比例高一些。

lxzkenney · 2022 年1 月 14 日 10:01

我们所有的表都是自增整形ID，是不是跟写入热点有关系。

Meditator · 2022 年1 月 14 日 10:29

这种自增PK写入密集的时候，会形成热点。无法用到分布式的特性–多节点并行协同工作。

lxzkenney · 2022 年1 月 14 日 11:06

get 了，我把要压测写入的表都改造成auto_rand 方式，然后下次压测，看下效果。我再反馈一下。

Meditator · 2022 年1 月 15 日 05:59

嗯，创建表的时候可以创建非聚簇表，这样也有自增id 的PK，但是数据组织（region的切分t{table_id}_r{_tidb_row_id}）是按隐藏的_tidb_row_id来组织的。而_tidb_row_id的产生可以指定shard_row_id_bits来分片产生，再加上pre_split_regions选项，就可以起到打散数据的目的。

system · 2022 年10 月 31 日 19:10

此话题已在最后回复的 1 分钟后被自动关闭。不再允许新回复。