2016-12-06 56 views
3

我在本地“启动”Docker容器(独立于Kafka节点容器)以分布模式启动Kafka连接器。连接器按预期工作,但是当我杀死启动容器时,连接器停止工作。我预计它会继续工作,因为我相信它是在另一个容器中的Kafka节点上的一名工作人员上进行注册和运行的。我的设置更详细如下:为什么当我创建节点时,Kafka分布式连接器会死亡?

目前我通过Docker容器在本地运行所有内容。我有:

  1. 动物管理员节点(3.4.9)
  2. 卡夫卡节点(Apache的,0.10.1.0)
  3. A '推出' 节点。

启动节点下载相应的Kafka版本并解压缩它的内容。然后它建立连接器源,设置类路径以包括必要的JAR,然后执行该连接器为这样:

connect-distributed.sh config/connect-distributed.properties 

分布式属性文件设置分组ID,各种主题名称,模式和转换器以及还有引导程序服务器(指向上面的Kafka节点(2))。

该命令似乎正常执行,并且restful连接器http服务已成功启动。然后,我可以将POST请求发送到http://example:8083/connectors,为连接器任务提供配置。该命令完成后没有错误,并且连接器已成功启动。我可以从Kafka节点(2)中的主题中消费,并且看到指示连接器正在工作并通过发送数据的输出。

当我杀死启动节点(3)时,我预计连接器会继续运行,因为我已将它注册到Kafka集群,尽管它是一个集群。连接器不会继续运行,似乎与启动节点一起死亡。连接器是否应该由群集中的工作人员管理?我是否需要更改连接器的启动方式,或者我误解了某些内容?

回答

3

卡夫卡连接器不执行卡夫卡经纪人。它们在“Kafka Connect Worker”进程中执行,这就是您的问题称为“启动”节点的问题。这些进程接受连接器的REST请求,并在工作进程中运行连接器。在这个幌子下,这些流程只是通过正常的生产者和消费者与卡夫卡经纪人进行交互。 Kafka Connect在这些客户端之上提供了一个框架,以便于构建可扩展的连接器,因此连接器开发人员只需将注意力集中在如何将数据拖放到连接器编写的系统上。这意味着只有至少有一个工作进程仍然存在时,处理才会继续。

有两种类型的工作进程。在独立模式下,连接器配置不会在任何地方持久 - 您通常通过命令行将其传入。偏移信息(即您已复制的数据)保存在本地文件系统中。因此,在这种模式下,如果您在同一个节点上重新启动进程并访问相同的文件系统,则只能假定您将恢复到原来的位置。

在分布式模式下,工作人员协调分配工作,并共享连接器配置,偏移量等常见的持久存储(在Kafka中)。这意味着如果启动一个实例并创建连接器,该实例将停止所有工作。但是,当您再次启动实例时,它将从停止的位置恢复,而不重新提交连接器配置,因为该信息已保存到Kafka。如果启动多个实例,它们将协调负载平衡它们之间的任务,并且如果一个实例失败(由于崩溃,弹性缩减正在运行的实例数量,电源故障等),其余实例将重新分配自动工作。

您可以找到有关人员,不同类型的详细信息,并在故障转移分布式模式如何运作in Confluent's Kafka Connect documentation

+0

感谢您的回答。所以这意味着我的Kafka节点配置的一部分应该启动连接器,如果我想要一个工作进程在我的Kafka集群中的每个节点上运行至少一个连接器任务?第二个问题:如果连接器出于某种原因失败,我需要监视连接器状态主题,该主题将在必要的节点上自动重启它。 – LaserJesus

+1

工作人员自动分配任务,只要您至少启动一个连接器并拥有足够的任务,所有工作人员都将主动处理数据。对于监控,是的,您可以监控状态主题并采取适当的措施重新启动(* if *有意义;这可能是其他系统的问题,只有通过重新启动任务才能解决)。 –

+0

再次感谢您的帮助。因此,如果我的Kafka集群中有三个节点,我应该在每个节点上启动连接器,让工作人员在每个节点上为该连接器运行任务,以确保如果单个节点出现故障,将会有连接器在工作站上运行其他节点?即在一个节点上启动连接器不会自动导致连接器及其各自的工作人员在其他节点上启动? – LaserJesus

相关问题