• -------------------------------------------------------------
  • ====================================

debezium 经验和踩坑

大数据库 dewbay 6年前 (2019-06-10) 10975次浏览 已收录 0个评论 扫描二维码

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,来做到正真的资源隔离,互不影响。当然这个我没有尝试过 ~.~ 。

大概就这些吧。


露水湾 , 版权所有丨如未注明 , 均为原创丨本网站采用BY-NC-SA协议进行授权
转载请注明原文链接:debezium 经验和踩坑
喜欢 (20)
[]
分享 (0)
关于作者:
发表我的评论
取消评论

表情 贴图 加粗 删除线 居中 斜体 签到

Hi,您需要填写昵称和邮箱!

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址