在Kafka集群之间进行复制

2 年 ago

清, 扬

2 minutes

首先-

Apache Kafka是一种实现高可用性和高可靠性的分布式消息系统，我相信很少会出现集群宕机或数据丢失的情况。
但是，由于灾害或网络故障等原因，可能会导致集群无法使用，因此有时需要准备灾难恢复（DR）站点作为预防措施。

在Kafka中，有一个名为Mirror Maker的复制工具被默认打包在一起，用于在集群之间实现复制。
Mirror Maker是一个独立于Kafka的进程，它作为源头consumer消费指定的主题，并将其发布到目标主题中。由于这是一个异步操作，所以两个集群之间的所有消息无法完全匹配。
然而，通过在Mirror Maker中启动多个进程，可以减少延迟。

本次我们将安装Mirror Maker并验证其是否能够进行复制。

此外，DR网站虽然是Mirror Maker的一个应用案例，但还有其他各种应用场景，例如为远程地区的不同应用程序创建集群副本等。

环境

我們將使用以下的環境和軟體。

kafka 2.2.1

尽管在这里不会详细说明Kafka的安装步骤，但如果只需要单机配置，可以轻松地在以下网站上找到安装指南。（多节点集群配置也很简单）

Quickstart – 公式サイト

制作镜像工具的准备

Mirror Maker将根据以下网站作为参考进行构建。
不过，由于它已经包含在kafka中，实际上只需创建属性文件并启动即可。

Apache Kafka Mirror Maker

在启动Mirror Maker之前，请先启动源镜像和目标镜像的Zookeeper和Kafka。

$ cd /opt/kafka/
$ bin/zookeeper-server-start.sh config/zookeeper.properties
$ bin/kafka-server-start.sh config/server.properties

而且，我们还要在Mirror原项目和Mirror目标项目中创建话题（test）。
虽然后面会出现最佳实践，但好像在Mirror目标项目中也最好先创建话题。

$ /opt/kafka/bin/kafka-topics.sh --create --bootstrap-server localhost:9092 --replication-factor 1 --partitions 3 --topic test

启动Mirror Maker。

在Mirror Maker的目录下，即/opt/kafka/config，创建以下两个文件。

mirror-producer.properties（ミラー先への接続用）

镜像-消费者.properties 文件已按照以下方式进行设置。

# ミラー元kafkaサーバへの接続情報。複数サーバの場合は","区切りで指定
bootstrap.servers=kafkaserver1:9092
# consumerのグループID
group.id=mirror-consumer-group
exclude.internal.topics=true
client.id=mirror_maker_consumer

mirror-producer.properties的设置如下。

bootstrap.servers=kafkaserver2:9092
acks=1
batch.size=100
client.id=mirror_maker_producer

一旦创建了设置文件后，只需要使用以下命令启动Mirror Maker。
考虑到无法连接的情况，建议在镜像目标集群上启动Mirror Maker。

$ cd /opt/kafka
$ bin/kafka-mirror-maker.sh --consumer.config config/mirror-consumer.properties --producer.config config/mirror-producer.properties --whitelist test

通过使用白名单选项指定要进行复制的主题列表。可以在此选项中使用正则表达式。由于只有一个测试主题，因此直接指定它。如果指定*，则会复制所有主题。

确认

为了确认，我们将使用kafka-console-producer.sh在源环境中向test主题发布一条消息。

bin/kafka-console-producer.sh --broker-list localhost:9092 --topic test
>a   
>b
>c
>

确认连接到Mirror源的消费者组。

# bin/kafka-consumer-groups.sh --bootstrap-server localhost:9092 --list
mirror-consumer-group
console-consumer-87140

上面显示的mirror-consumer-group是Mirror Maker的消费者群组。
在发布消息后，确认了mirror-consumer-group的偏移量的结果如下：
如果LAG为”0″，则表示所有消息的同步已经完成。

# bin/kafka-consumer-groups.sh --bootstrap-server localhost:9092 --describe --group mirror-consumer-group

TOPIC           PARTITION  CURRENT-OFFSET  LOG-END-OFFSET  LAG             CONSUMER-ID                                                  HOST            CLIENT-ID
test            0          8               8               0               mirror-consumer-group-0-3787bef8-7ff8-461e-a95c-c598ed0b05f7 /192.168.10.135 mirror-consumer-group-0
test            1          9               9               0               mirror-consumer-group-0-3787bef8-7ff8-461e-a95c-c598ed0b05f7 /192.168.10.135 mirror-consumer-group-0
test            2          9               9               0               mirror-consumer-group-0-3787bef8-7ff8-461e-a95c-c598ed0b05f7 /192.168.10.135 mirror-consumer-group-0

最佳实践主题

在以下页面中记载了有关创建话题的最佳实践。

Apache Kafka Mirror Maker

在目标群集中创建主题

如果你有消费者要从目标群集中消费数据，且消费者的并行需求与源群集相同，那么很重要的一点是在目标群集中创建一个相同分区数量的同名主题。

例如：

如果你在源群集中有一个名为“click-logs”的主题，有6个分区，那么确保在目标群集中也有相同数量的分区。如果你将目标群集用作备份而不是主动使用，可能不需要相同的分区数量。

如果用户没有在目标群集中创建主题，镜像制造者中的生产者将试图创建一个主题，目标群集代理将使用配置的分区数量和副本数量创建主题，这可能不是用户想要的分区和副本数量。

要点就是事先准备好一个主题给镜子。

执行故障转移后

フェイルオーバー後、以前のアクティブノードは新しいスタンバイノードとして役割を果たします。
以前のアクティブノードから新しいアクティブノードに切り替えた場合、データの損失が発生している可能性があり、以前のアクティブノードをそのまま新しいスタンバイノードとはしません。
すべてのデータをクリアしてから、新しいスタンバイノードとして使用することになるでしょう。
今回は試してみませんが。

除了MirrorMaker之外的其他选择。

有一款名为”Confluent Replicator”的产品是付费的。
以下是与Mirror Maker的比较，这款产品似乎比Mirror Maker功能更丰富。

Comparing MirrorMaker to Confluent Replicator

最后

在介绍了在集群之间执行复制的步骤后，需要考虑以下内容才能在生产环境中实际采用。

etc

请在中国本土进行参考。

Comparing MirrorMaker to Confluent Replicator