对debezium
的运维和使用大半年时间。曾经管理的单个debezium
集群有10
个左右的debeizum
任务。某个库的debezium
订阅的表数量大概有几十个,得出了很多经验,踩了很多坑。下面会列出各种遇到的问题和一些比较不错的实践。
踩坑
debezium
坑很多!!最大的坑就是kafka connect
的rebalance
;每当有新的debezium connector
被发到集群后,就会触发集群的rebalance
;集群内部的connector
任务开始重启,表面上看任务重新分配,每个debezium
实例都能均匀的分配到任务,确实很优雅。但是事实上重启集群内部所有的connector
一个很重的操作。由于本身debezium
的一些不优雅的特性,导致重启有可能造成集群内多个connector
挂掉。所以需要尽可能的少触发集群的rebalance
; 不过这个巨坑其实很难避免。
其它的几个大坑:
debezium
的history topic
不能被多个connector
共用。如果新的connector
使用了集群内某个connector
正在使用的history topic
,集群内的正在使用history topic
的connector
会抛出异常终止(这个在0.5.x版本的时候,并不会抛出异常!!)。- 竟可能的每个库对应一个
connector
,每个connector
只订阅需要接入debezium
的某个库内的表。可以通过设置库的白名单和表的白名单实现。(一个任务订阅多个库、多个表是非常不正确的行为,后续新增表代价会非常大) debezium connector
重启并不是每次都成功的,也即是说connector
重启可能会导致任务挂掉。history topic
可能会非常的大,connector
重启时会读取history topic
所有数据,如果history topic
数据量非常的大,connector
可能就无法在给定的时间内启动,connector
抛出异常启动失败。- 坑
3
这个坑遇上rebalance
,就会出现比较严重的问题。如果集群内有多个connector
,并且多个connector
的histroy topic
都很大,那rebalance
之后,这些connector
很有可能都会重启失败。 - 坑
1
和rebalance
也有关系。debezium
集群内connector
数量很多时,重启可能会发生history topic
被共用的异常,但是事实上我们并没有共用!!
建议
- 一个
debezium
内尽量不要运行太多的connector
。相同数量的机器情况下,多集群的效果会比单集群多服务器好很多! - 把很重的
connector
迁到单独的集群。比如我所在的公司,需要订阅一个库内几十个表,这就导致任务的重启非常的慢,停掉任务就要花很长时间,如果和其它connector
部署在一起,不是很好!(理由自己想) - 推荐将
debezium
部署到k8s
,集群扩容、缩容会很方便。 - 可以尝试将每个
connector
对应一个k8s pod
,来做到正真的资源隔离,互不影响。当然这个我没有尝试过~.~
。
大概就这些吧。