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

ticdc 版本 5.0.1

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

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

image

从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\ngithub.com/pingcap/errors.AddStack\n\tgithub.com/pingcap/errors@v0.11.5-0.20201126102027-b0 a155152ca3/errors.go:174\ngithub.com/pingcap/errors.(*Error).GenWithStackByCause\n\tgithub.com/pingcap/errors@v0.11.5-0.20201126102027-b0a155152ca3/normalize.go:279\ngithub.com/pin gcap/ticdc/pkg/errors.WrapError\n\tgithub.com/pingcap/ticdc@/pkg/errors/helper.go:28\ngithub.com/pingcap/ticdc/pkg/version.CheckStoreVersion\n\tgithub.com/pingcap/ticdc@/pkg/versio n/check.go:128\ngithub.com/pingcap/ticdc/cdc/kv.(*CDCClient).newStream.func1\n\tgithub.com/pingcap/ticdc@/cdc/kv/client.go:427\ngithub.com/pingcap/ticdc/pkg/retry.Run.func1\n\tgith ub.com/pingcap/ticdc@/pkg/retry/retry.go:32\ngithub.com/cenkalti/backoff.RetryNotify\n\tgithub.com/cenkalti/backoff@v2.2.1+incompatible/retry.go:37\ngithub.com/cenkalti/backoff.Ret ry\n\tgithub.com/cenkalti/backoff@v2.2.1+incompatible/retry.go:24\ngithub.com/pingcap/ticdc/pkg/retry.Run\n\tgithub.com/pingcap/ticdc@/pkg/retry/retry.go:31\ngithub.com/pingcap/tic dc/cdc/kv.(*CDCClient).newStream\n\tgithub.com/pingcap/ticdc@/cdc/kv/client.go:421\ngithub.com/pingcap/ticdc/cdc/kv.(*eventFeedSession).dispatchRequest\n\tgithub.com/pingcap/ticdc@ /cdc/kv/client.go:788\ngithub.com/pingcap/ticdc/cdc/kv.(*eventFeedSession).eventFeed.func1\n\tgithub.com/pingcap/ticdc@/cdc/kv/client.go:575\ngolang.org/x/sync/errgroup.(*Group).Go .func1\n\tgolang.org/x/sync@v0.0.0-20201020160332-67f06af15bc9/errgroup/errgroup.go:57\nruntime.goexit\n\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% ,不清楚这个线程是什么意思。
image

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1)实际上,cdc监听了上游tidb中多个表?
2)这里sorter排序用到了磁盘,请问磁盘是什么类型的盘?
image
3)排序方式为unified,默认优先使用内存,超过内存限制(2个指标:内存分配默认 16G、当前系统可用内存百分比),或者下游写入慢,触发流控,都会触发磁盘缓存,有没有用到磁盘缓存,可以看 ticdc 监控项 Unified Sorter-Unified Sorter on disk data size
参考这里 ticdc unified sorter 几个疑问
建议cdc 内存配置比例高一些。

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

cdc tikv13.log.gz (20.0 MB) tikv 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节点。

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

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

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

image

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

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

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