@heming Hello ~ 麻烦提供一下 TiCDC 的相关日志以及通过 Metrictool 导出一下问题时间点的监控,包括 PD 和 TiCDC 的所有监控数据,我们再排查一下。
ticdc 日志太大了 节点太多了 6个节点 ,看看 提供 17.92 17.185 这两个当时 曾经作为owner 又 快速 降级为worker的当时的日志可以吗?
可以,提供一下哈吧,按照问题发生时间段提供一下。
[2021/11/18 21:31:54.034 +08:00] [WARN] [mysql.go:218] [“execute DDL with error, retry later”] [query=“alter table tbl_new_ssp_ad_log_20211119 add key appid_uid_ac_adt(user_id,ac,adtype,appid)”] [error="[CDC:ErrMySQLTxnError]invalid connection"] [errorVerbose="[CDC:ErrMySQLTxnError]invalid connection![](file:///C:\Users\heming\AppData\Roaming\Tencent\QQTempSys`7_{~]GF$3{MOQ4V_}PH]YC.png)ngithub.com/pingcap/errors.AddStack\ ![](file:///C:\Users\heming\AppData\Roaming\Tencent\QQ\Temp%W@GJ$ACOF(TYDYECOKVDYB.png)tgithub.com/pingcap/errors@v0.11.5-0.20201126102027-b0a155152ca3/errors.go:174![](file:///C:\Users\heming\AppData\Roaming\Tencent\QQTempSys`7_{~]GF$3{MOQ4V_}PH]YC.png)ngithub.com/pingcap/errors.(*Error).GenWithStackByCause\ ![](file:///C:\Users\heming\AppData\Roaming\Tencent\QQ\Temp%W@GJ$ACOF(TYDYECOKVDYB.png)tgithub.com/pingcap/errors@v0.11.5-0.20201126102027-b0a155152ca3/normalize.go:279![](file:///C:\Users\heming\AppData\Roaming\Tencent\QQTempSys`7_{~]GF$3{MOQ4V_}PH]YC.png)ngithub.com/pingcap/ticdc/pkg/errors.WrapError\ ![](file:///C:\Users\heming\AppData\Roaming\Tencent\QQ\Temp%W@GJ$ACOF(TYDYECOKVDYB.png)tgithub.com/pingcap/ticdc/pkg/errors/helper.go:30![](file:///C:\Users\heming\AppData\Roaming\Tencent\QQTempSys`7_{~]GF$3{MOQ4V_}PH]YC.png)ngithub.com/pingcap/ticdc/cdc/sink.(*mysqlSink).execDDL\ ![](file:///C:\Users\heming\AppData\Roaming\Tencent\QQ\Temp%W@GJ$ACOF(TYDYECOKVDYB.png)tgithub.com/pingcap/ticdc/cdc/sink/mysql.go:261![](file:///C:\Users\heming\AppData\Roaming\Tencent\QQTempSys`7_{~]GF$3{MOQ4V_}PH]YC.png)ngithub.com/pingcap/ticdc/cdc/sink.(*mysqlSink).execDDLWithMaxRetries.func1\ ![](file:///C:\Users\heming\AppData\Roaming\Tencent\QQ\Temp%W@GJ$ACOF(TYDYECOKVDYB.png)tgithub.com/pingcap/ticdc/cdc/sink/mysql.go:212![](file:///C:\Users\heming\AppData\Roaming\Tencent\QQTempSys`7_{~]GF$3{MOQ4V_}PH]YC.png)ngithub.com/pingcap/ticdc/pkg/retry.run\ ![](file:///C:\Users\heming\AppData\Roaming\Tencent\QQ\Temp%W@GJ$ACOF(TYDYECOKVDYB.png)tgithub.com/pingcap/ticdc/pkg/retry/retry_with_opt.go:54![](file:///C:\Users\heming\AppData\Roaming\Tencent\QQTempSys`7_{~]GF$3{MOQ4V_}PH]YC.png)ngithub.com/pingcap/ticdc/pkg/retry.Do\ ![](file:///C:\Users\heming\AppData\Roaming\Tencent\QQ\Temp%W@GJ$ACOF(TYDYECOKVDYB.png)tgithub.com/pingcap/ticdc/pkg/retry/retry_with_opt.go:32![](file:///C:\Users\heming\AppData\Roaming\Tencent\QQTempSys`7_{~]GF$3{MOQ4V_}PH]YC.png)ngithub.com/pingcap/ticdc/cdc/sink.(*mysqlSink).execDDLWithMaxRetries\ ![](file:///C:\Users\heming\AppData\Roaming\Tencent\QQ\Temp%W@GJ$ACOF(TYDYECOKVDYB.png)tgithub.com/pingcap/ticdc/cdc/sink/mysql.go:211![](file:///C:\Users\heming\AppData\Roaming\Tencent\QQTempSys`7_{~]GF$3{MOQ4V_}PH]YC.png)ngithub.com/pingcap/ticdc/cdc/sink.(*mysqlSink).EmitDDLEvent\ ![](file:///C:\Users\heming\AppData\Roaming\Tencent\QQ\Temp%W@GJ$ACOF(TYDYECOKVDYB.png)tgithub.com/pingcap/ticdc/cdc/sink/mysql.go:201![](file:///C:\Users\heming\AppData\Roaming\Tencent\QQTempSys`7_{~]GF$3{MOQ4V_}PH]YC.png)ngithub.com/pingcap/ticdc/cdc/owner.(*asyncSinkImpl).run\ ![](file:///C:\Users\heming\AppData\Roaming\Tencent\QQ\Temp%W@GJ$ACOF(TYDYECOKVDYB.png)tgithub.com/pingcap/ticdc/cdc/owner/async_sink.go:132\ runtime.goexit\ \truntime/asm_amd64.s:1371"]
(user:tidbdba time: 21:33)[db: cbd_user_behavior_analysis]admin show ddl jobs;
±-------±---------------------------±----------------------------±--------------±---------------------±----------
| JOB_ID | DB_NAME | TABLE_NAME | JOB_TYPE | SCHEMA_STATE | SCHEMA_ID | TABLE_ID | ROW_COUNT | START_TIME | END_TIME | STATE |
±-------±---------------------------±----------------------------±--------------±---------------------±----------
| 32751 | cbd_user_behavior_analysis | tbl_new_ssp_ad_log_20211118 | add index | write reorganization | 318 | 32629 | 24518740 | 2021-11-18 21:05:39 | NULL | running |
下游在执行ddl ,其他的dml 也被阻塞了,ticdc 等待这个ddl的执行 ,按说这种不应该阻塞
[root@yz-mbg-017012 ~]# cdc cli changefeed list --pd=http://xx.xx.17.37:2479
[
{
“id”: “cbd-user-behavior-analysis-task”,
“summary”: {
“state”: “normal”,
“tso”: 429192872526872686,
“checkpoint”: “2021-11-18 21:07:57.254”,
“error”: {
“addr”: “123.59.17.57:8301”,
“code”: “CDC:ErrOwnerUnknown”,
“message”: “[CDC:ErrReachMaxTry]reach maximum try: 20”
}
}
},
感觉比较像这个已知 bug https://github.com/pingcap/ticdc/issues/2254,目前 owner 卡住就有可能引起类似的 bug。请问 @heming 表数量大概有多少?现在表多的情况比较容易出现该 bug
上游700多 下游200多
cdc 5.1.2最多能监听的表数(产品边界)应该不超过2k.
上游700多个表,有多个changefeed, 对于cdc来说监听的表数是:上游表数 * changfeed 个数。
从你的监控来看,每个capture 监听1.39k table count, 那么监听的表数是 1.39k * 6 capture = 8.34k, 超过了产品边界。
建议减少表的个数,比如changfeed中增加filter.rules, 只同步某些表;或者减少changefeed个数。
麻烦再次出现该问题的时候抓一次 goroutine profile,具体步骤如下:
- 浏览器输入 http://$host:$port/debug/pprof/goroutine
- 保存并上传抓取到的文件
问题出现,或者复现的时候,会把文件传上来
日志
17.88.log.gz (662.0 KB)
17.92.log.gz (710.0 KB)
17.57.log.gz (1.6 MB)
17.58.log.gz (654.4 KB)
17.217.log.gz (701.2 KB)
17.185.log.gz (681.4 KB)
@heming @foxchan Hi 经过分析看,目前是已经达到资源瓶颈,目前通过拆解 changfeed 不能解决根本的资源占用问题,如果可以,建议增加 TiCDC 的资源配置或者增加 TiCDC 节点。 TiCDC Owner 不是没有选出,而是当前 Owner 主线程卡住。同步的表数量较多,约为 8000 个。在卡住之前出现了 changefeed 重启引发的调度。
好的,多谢
ticdc能不能指定只抓取某几个数据库的变更日志 。