TiCDC 4.0.15 初体验

这里将CDC 4.0.15使用做一下总结,方便后续查阅。

这边的生产集群是从 4.0.11 升级到 4.0.15

CDC监控图表

1、图表可以看到CPU和内存使用率降低了很多。goroutine线程数也减少了非常多。

2、稳定了很多,升级了2周CDC没有自动重启过,不像 4.0.11 经常自动重启。

3、每个changefeed执行DDL都是异步调用,并不会影响其他DDL的执行。

下面是日志,可以看到DDL现在是异步调用。
[2021/12/14 15:09:21.967 +08:00] [INFO] [async_sink.go:132]
[“Execute DDL succeeded”] [changefeed=cs-mysql] [ignored=true]
[ddl="{“StartTs”:429776112279617537,“CommitTs”:429776112279617540,“TableInfo”:{“Schema”:“cdkk”,“Table”:“t1”,“TableID”:5189,“ColumnInfo”:[{“Name”:“id”,“Type”:3},{“Name”:“pad1”,“Type”:15},{“Name”:“pad2”,“Type”:15},{“Name”:“pad3”,“Type”:15},{“Name”:“create_time”,“Type”:12},{“Name”:“age4”,“Type”:15},{“Name”:“age6”,“Type”:15},{“Name”:“age11”,“Type”:15},{“Name”:“ka”,“Type”:15}]},“PreTableInfo”:{“Schema”:“cdkk”,“Table”:“t1”,“TableID”:5189,“ColumnInfo”:[{“Name”:“id”,“Type”:3},{“Name”:“pad1”,“Type”:15},{“Name”:“pad2”,“Type”:15},{“Name”:“pad3”,“Type”:15},{“Name”:“create_time”,“Type”:12},{“Name”:“age4”,“Type”:15},{“Name”:“age6”,“Type”:15},{“Name”:“age11”,“Type”:15}]},“Query”:“ALTER TABLE t1 ADD ka varchar(50)”,“Type”:5}"]

4、当前 changefeed 的下游 MySQL 执行DDL时(包括加字段、加索引、修改字段长度),后续所有DML语句都会阻塞,同步会延迟。 这里要注意,如果下游DDL没有执行完。tidb 就开始大批量跑数据可能导致CDC内存积压。

5、这边的排序方式使用的 memory ,还未体验 Unified Sorter 。

6、同步速度
单个同步任务往下游MySQL同步速度没有之前的快了,单个任务平均每分钟往下游同步3万-4万条数据左右,单行平均长度在1000-2000个字节左右。 而改成drainer可以跑到10万+。
尝试了调大 worker-count=64&max-txn-row=5000 ,和 mounter 为 16 也没有效果。

怎么样来提升单个同步任务的速度,有知道的小伙伴告知一下。

7、当下游执行DDL时间过长时,CDC会不断的向下游发送DDL语句直到执行完成。当重试次数达到20次以上同步任务就会报错:[CDC:ErrReachMaxTry]reach maximum try: 20,等下游DDL执行完成后重新启动任务即可。

{
“id”: “cdkk-mysql”,
“summary”: {
“state”: “stopped”,
“tso”: 429776112279617539,
“checkpoint”: “2021-12-14 15:09:20.344”,
“error”: {
“addr”: “172.16.188.120:8300”,
“code”: “CDC:ErrExecDDLFailed”,
“message”: “[CDC:ErrReachMaxTry]reach maximum try: 20”
}
}
}

5赞

在4.0.14 压测了快3周了,挺稳定了 之前4.0.8 、0.9 也除各种问题 ,对于创建过的taskname无法重新使用,通过processor可以看到 这个一直没研究出来 怎么清理

3赞

你指定的是一些有问题的 taskname 无法完全清理,而无法创建同名的同步任务吗? 4.0.11 也一直有这个问题, 我已经放弃了。

2赞

喔唷~板凳~

3赞

嗯 是的 processor list,研究了半天pd里的etcd操作,没结果,也是放弃了,:sweat_smile:

2赞

可以看看admin show ddl jobs? 是不是TIDB-SERVER出现统计信息版本不一致了,看下DDL的owner是谁

2赞

目前还遇到一个问题:怎么让下游能够负载均衡呢,比如sink-uri通过域名连接,下游绑定了3个TIDB-SERVER 服务,怎么能够均衡呢,用HAPROXY是没法做到

2赞

不断发送DDL这个是CDC的正常逻辑的。

负载均衡这个场景我也没遇到过。HAPROXY多数都是按连接来做均衡的。 单个同步任务应该只会连接到一个tidb-server 。 可以按库或按表来拆分成多个同步任务? 这样就会均衡一些吧。

2赞

taskname 指的是 changefeed-id 么。

如果是的话,需要在执行 remove changefeed 时,使用 -f 参数。比如:

cdc cli changefeed remove pd=http://127.0.0.1:2379 --changefeed-id="abcd" -f

然后再创建相同 changefeed-id 的 changefeed,应该是可以成功的。

3赞

加上-f 也没有用,在元数据信息里面仍然有残留的。 等待后续版本看看会不会对这块优化。

2赞

这个数据 应该事在ETCD,就是不知道怎么操作

1赞