Hi, Franz!
I guess, one of the reasons could be additional safety in case of network split.
It is also some probability of bugs even with good software. So, If we place MM
on source cluster and network will split, consumers could (theoretically)
continue to read messages from source cluster and
ienstag, 12. März 2019 um 16:24 Uhr
> Von: "Peter Bukowinski" mailto:pmb...@gmail.com>>
> An: users@kafka.apache.org <mailto:users@kafka.apache.org>
> Betreff: Re: Kafka Mirror Maker place of execution
> I have a setup with about 30 remote kafka clusters and one c
An: users@kafka.apache.org
Betreff: Re: Kafka Mirror Maker place of execution
I have a setup with about 30 remote kafka clusters and one cluster in a core
datacenter where I aggregate data from all the remote clusters. The remote
clusters have 30 nodes each with moderate specs. The core cluster has 100 n
s"
Betreff: Re: Kafka Mirror Maker place of execution
Franz, you can run MM on or near either source or target cluster, but it's
more efficient near the target because this minimizes producer latency. If
latency is high, poducers will block waiting on ACKs for in-flight records,
whi
I have a setup with about 30 remote kafka clusters and one cluster in a core
datacenter where I aggregate data from all the remote clusters. The remote
clusters have 30 nodes each with moderate specs. The core cluster has 100 nodes
with lots of cpu, ram, and ssd storage per node.
I run MirrorMa
Franz, you can run MM on or near either source or target cluster, but it's
more efficient near the target because this minimizes producer latency. If
latency is high, poducers will block waiting on ACKs for in-flight records,
which reduces throughput.
I recommend running MM near the target cluster
Hi all,
there are best practices out there which recommend to run the Mirror Maker on
the target cluster.
https://community.hortonworks.com/articles/79891/kafka-mirror-maker-best-practices.html
I wonder why this recommendation exists because ultimately all data must cross
the border between the
