[
https://issues.apache.org/jira/browse/KAFKA-7500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16931743#comment-16931743
]
Qihong Chen edited comment on KAFKA-7500 at 9/17/19 7:22 PM:
-------------------------------------------------------------
Hi [~ryannedolan], just listened your Kafka Power Chat talk, Thanks!
Have a follow up question about the last question (from me) you answered in the
talk. You said you prefer dedicated MM2 cluster over running MM2 in connect
cluster since you can use less number of clusters to do replications among
multiple Kafka clusters.
But there's no REST Api for a dedicated MM2 cluster that can provide the status
of the replication streams, nor updating the replication configuration. Any
changes to the configuration meaning update the config files and restart all
MM2 instances, is that right? Or I missed it that dedicated MM2 cluster does
provide REST API for admin and monitoring, if so, where is it?
If my understanding is correct, we can archive the same thing with MM2 in
connect cluster. Assume there are 3 Kafka clusters: A, B, and C. Set up a
connect cluster against C (meaning all topics for connectors' data and states
go to cluster C), then set up MM2 connectors to replicate data and metadata A
-> B and B -> A. If this is correct, we can use the Kafka cluster C plus the
connect cluster that running against Kafka cluster C to replicate data among
more Kafka clusters, like A, B, and D, and even more. Of course, this needs
more complicated configuration, which requires deeper understanding how the MM2
connectors work. In this scenario, the connect cluster provides REST API to
admin and monitoring all the connectors. This will be useful for people can't
use Stream Replication Manager from Cloudera or Kafka replicator from Confluent
for some reason. Is this right?
was (Author: qihong):
Hi [~ryannedolan], just listened your Kafka Power Chat talk, Thanks!
Have a follow up question about the last question (from me) you answered in the
talk. You said you prefer dedicated MM2 cluster over running MM2 in connect
cluster since you can use less number of clusters to do replications among
multiple Kafka clusters.
But there's no REST Api for a dedicated MM2 cluster that can provide the status
of the replication streams, nor updating the replication configuration. Any
changes to the configuration meaning update the config files and restart all
MM2 instances, is that right? Or I missed it that dedicated MM2 cluster does
provide REST API for admin and monitoring, if so, where is it?
If my understanding is correct, we can archive the same thing with MM2 in
connect cluster. Assume there are 3 Kafka clusters: A, B, and C. Set up a
connect cluster against C (meaning all topics for connectors' data and states
go to cluster C), then set up MM2 connectors to replicate data and metadata A
-> B and B -> A. If this is correct, we can use the Kafka cluster C plus the
connect cluster that running against Kafka cluster C to replicate data among
more Kafka clusters, like A, B, and D, and even more. Of course, this needs
more complicated configuration, which requires deeper understanding how the MM2
connectors work. In this scenario, the connect cluster provides REST API to
admin and monitoring all the connectors. This will be useful for people can't
use Stream Replication Manager from Cloudera or Kafka replicator from Confluent
for some reason. Is this right?
> MirrorMaker 2.0 (KIP-382)
> -------------------------
>
> Key: KAFKA-7500
> URL: https://issues.apache.org/jira/browse/KAFKA-7500
> Project: Kafka
> Issue Type: New Feature
> Components: KafkaConnect, mirrormaker
> Affects Versions: 2.4.0
> Reporter: Ryanne Dolan
> Assignee: Manikumar
> Priority: Major
> Labels: pull-request-available, ready-to-commit
> Fix For: 2.4.0
>
> Attachments: Active-Active XDCR setup.png
>
>
> Implement a drop-in replacement for MirrorMaker leveraging the Connect
> framework.
> [https://cwiki.apache.org/confluence/display/KAFKA/KIP-382%3A+MirrorMaker+2.0]
> [https://github.com/apache/kafka/pull/6295]
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
