Ryanne, thank you!
Now it is clear, why offsets on rc behave like this.
Tolya
5 марта 2019 г., в 20:05, Ryanne Dolan
mailto:ryannedo...@gmail.com>> написал(а):
Tolya,
You mentioned that you are replicating "with internal topics", so I'd
expect the __consumer_offsets topic in the target cluste
Tolya,
You mentioned that you are replicating "with internal topics", so I'd
expect the __consumer_offsets topic in the target cluster to include (at
least) the same records as the source cluster. MirrorMaker does not
translate offsets, so the downstream commits will be wrong if you try to
replica
Hello, Ryanne and thank you for you answer!
I am using idempotent producers. And you are right, I started replication after
few days and some of source data were already deleted (because of retention) at
that moment.
Still I couldn’t understand logic behind Kafka-consumer-groups. With console
Tolya,
That is the expected behavior. Offsets are not consistent between mirrored
clusters.
Kafka allows duplicate records ("at least once"), which means the
downstream offsets will tend to creep higher than those in the source
partitions. For example, if a producer sends a record but doesn't rec
Hello, guys!
I am not sure about offsets replicated by MirrorMaker.
I am replicating data from one Kafka cluster (let's say cluster A, Confluent
Kafka 2.0) to another (cluster B, Confluent Kafka 2.1) with internal topics.
MirrorMaker lag is somewhere between 1-2k events.
I started replication a
