debezium 经验和踩坑

对debezium的运维和使用大半年时间。曾经管理的单个debezium集群有10个左右的debeizum任务。某个库的debezium订阅的表数量大概有几十个，得出了很多经验，踩了很多坑。下面会列出各种遇到的问题和一些比较不错的实践。

踩坑

debezium坑很多！！最大的坑就是kafka connect的rebalance;每当有新的debezium connector被发到集群后，就会触发集群的rebalance;集群内部的connector任务开始重启，表面上看任务重新分配，每个debezium实例都能均匀的分配到任务，确实很优雅。但是事实上重启集群内部所有的connector一个很重的操作。由于本身debezium的一些不优雅的特性，导致重启有可能造成集群内多个connector挂掉。所以需要尽可能的少触发集群的rebalance; 不过这个巨坑其实很难避免。

其它的几个大坑:

1. debezium的history topic 不能被多个connector共用。如果新的connector使用了集群内某个connector正在使用的history topic，集群内的正在使用history topic的connector会抛出异常终止(这个在0.5.x版本的时候，并不会抛出异常!!)。
2. 竟可能的每个库对应一个connector，每个connector只订阅需要接入debezium的某个库内的表。可以通过设置库的白名单和表的白名单实现。(一个任务订阅多个库、多个表是非常不正确的行为，后续新增表代价会非常大)
3. debezium connector重启并不是每次都成功的，也即是说connector重启可能会导致任务挂掉。history topic可能会非常的大，connector重启时会读取history topic所有数据，如果history topic数据量非常的大，connector可能就无法在给定的时间内启动，connector抛出异常启动失败。
4. 坑3这个坑遇上rebalance，就会出现比较严重的问题。如果集群内有多个connector，并且多个connector的histroy topic都很大，那rebalance之后，这些connector很有可能都会重启失败。
5. 坑1和rebalance也有关系。debezium集群内connector数量很多时，重启可能会发生history topic被共用的异常，但是事实上我们并没有共用！！

建议

1. 一个debezium内尽量不要运行太多的connector。相同数量的机器情况下，多集群的效果会比单集群多服务器好很多！
2. 把很重的connector迁到单独的集群。比如我所在的公司，需要订阅一个库内几十个表，这就导致任务的重启非常的慢，停掉任务就要花很长时间，如果和其它connector部署在一起，不是很好!(理由自己想)
3. 推荐将debezium部署到k8s，集群扩容、缩容会很方便。
4. 可以尝试将每个connector对应一个k8s pod，来做到正真的资源隔离，互不影响。当然这个我没有尝试过 ~.~ 。

大概就这些吧。