备份/还原kafka和zookeeper

扎兰多最近发表了一篇很好的文章 how to backup Kafka and Zookeeper . Kafka备份通常有两条路径:

• 维护第二个Kafka集群,将所有主题复制到该集群。我还没有验证这个设置,但如果偏移主题也被复制,那么切换到另一个集群应该不会损害消费者的处理状态。
• 将主题转储到云存储,例如使用S3连接器(如Zalando所述)。在恢复的情况下,您可以重新创建主题,并向其提供来自云存储的数据。这将允许您进行时间点恢复,但消费者必须从头开始阅读主题。

首选的备份解决方案将取决于您的用例。E、 g.对于流媒体应用程序,第一种解决方案可能会减少您的痛苦,而当使用Kafka进行事件源时,第二种解决方案可能更可取。

关于Zookeeper,卡夫卡在那里保存关于主题的信息(持久存储),以及关于经纪人发现和领导人选举的信息(短暂的)。扎兰多决定使用 Burry ,它只需迭代Zookeeper树结构,将其转储到文件结构中,然后将其压缩并推送到云存储。它遭受 a little problem ,但它很可能不会影响卡夫卡持久数据的备份(TODO verify)。Zalando在那里描述说,在恢复时,最好先创建Zookeeper集群,然后将一个新的Kafka集群连接到该集群(使用新的、唯一的代理ID),然后恢复Burry的备份。Burry不会覆盖现有节点,也不会将有关旧代理的短暂信息、存储在备份中的内容放入。

注意:虽然他们提到了参展商的使用,但在与Burry备份时,实际上并不需要备份。

Apache Kafka已经使您的数据保持分布式,并提供强大的一致性 replication 能力。

首先,从架构设计的角度来看,我们需要了解备份对我们意味着什么?

• 它是为了在数据中心故障中幸存下来吗?

  正如您在评论中所说,想象一下,当您的整个数据中心都关闭时,这意味着该数据中心中运行的一切都消失了,而不仅仅是卡夫卡。要处理此类故障,您需要设计到不同数据中心的实时复制策略;您可以使用 kafka-mirror 制造商。您需要在不同的数据中心(不一定具有相同的硬件资源)中设置kafka群集,然后将当前的数据中心kafka配置为镜像到另一个数据中心。

在数据中心范围内发生故障的情况下,您的所有服务都将从此回退数据中心运行,并且它们将使用您的镜像卡夫卡作为主要卡夫卡。

然后,一旦另一个数据中心回来,您可以以相反的方式设置镜像,然后您可以回到您的旧(已销毁)数据中心。

• 它只是备份卡夫卡/动物园管理员的数据吗?

Kafka connect有两个现成的连接器,用于在一致性保证的情况下从Kafka传输数据。因此,也许您可以选择AWS S3作为备份存储,下面的连接器可以为您做到这一点。

• Confluent AWS S3 connector.

• Pinterest has secor service 将数据传输到AWS S3、Google和;Mircosoft云存储。 我相信你也可以为所有大型云提供商找到一些专用连接器。在将卡夫卡数据备份到高可用云存储时,需要考虑的事情很少。

• kafka对每个主题都有数据保留策略,因此旧数据将由kafka自己从kafka服务器中删除,但它仍将保留在您的AWS S3存储桶中,因此,如果在发生恢复事件时直接将其复制回来,那么您将在Kafka代理上看到更多数据,而且将整个数据恢复到现有的运行Kafka集群中也不是一个好主意,因为这样您将开始处理旧数据。所以要有选择性&在这个过程中要小心

• 对于zookeeper,您也可以将数据复制到AWS S3,但由于节点短暂,在恢复时需要小心。我发现了几个有帮助的链接:

https://jobs.zalando.com/tech/blog/backing-up-kafka-zookeeper/ https://www.elastic.co/blog/zookeeper-backup-a-treatise https://medium.com/@Pinterest_Engineering/zookeeper-resilience-at-pinterest-adfd8acf2a6b

最后,“预防胜于治疗”。因此,如果您在像AWS这样的云提供商设置中运行,那么您可以通过预先考虑故障来部署集群设置。下面的链接有一些信息。

https://aws.amazon.com/blogs/big-data/best-practices-for-running-apache-kafka-on-aws/