Hi! I am working with a 2 cluster geo-replication...
# general
a
Hi! I am working with a 2 cluster geo-replication set up with a global config store cluster (3 ZKs) all in Kubernetes. I am using Pulsar v4.0.8 and Helm chart v4.4.0. We are heavily testing geo-replication and I am wondering if the following is a bug? 2-way geo-replication has already been configured and enabled at the namespace level between Cluster A and Cluster B • Started a producer only first on Cluster A which auto created the topic under the geo-rep NS. (no consumers started anywhere yet) • Topic was successfully replicated and visible to Cluster B • Producer on Cluster A generated ~100 msgs • Consumer started on Cluster B, starts consuming at msg 101,102,103, so on .. • initial 100 messages sent by producer on cluster A never received by cluster B consumer and 100 messages are sitting in backlog • started consumer on cluster A and it receives all messages starting from message 1 and continues to consume the messages coming in to that topic along with cluster B consumer NOTE: this seems to only be happening when starting the cluster B consumer for the first time on the replicated topic. When the consumer is initially started briefly, then stopped, then started again, it receives all of the messages in the backlog that it missed before starting back up again. Is this a geo-replication bug?
l
Some replicated subscription problems were fixed in 4.0.9 with PR 25044 and PR 16651, please check https://apache-pulsar.slack.com/archives/C5Z4T36F7/p1772824988082859 or https://pulsar.apache.org/docs/4.1.x/administration-geo/#replicated-subscriptions-snapshot-configuration-and-tuning for detail. Please notice that Pulsar doesn't support having both consumers active in both clusters in replicated subscriptions. I documented such details to https://pulsar.apache.org/docs/4.1.x/administration-geo very recently so it's worth reading the whole document.
initial 100 messages sent by producer on cluster A never received by cluster B consumer and 100 messages are sitting in backlog
This detail is actually missed in the documentation. The subscription in cluster A and cluster B should be pre-created with replicated subscription enabled to avoid this problem.
If you would have created a consumer in cluster A with
.replicateSubscriptionState(true)
, the problem wouldn't be present.
that would also create the subscription in cluster B.
Is this a geo-replication bug?
No. It's just something that should be documented in the geo-replication documentation.
You can contribute by editing the page source directly: https://github.com/apache/pulsar-site/edit/main/docs/administration-geo.md and creating a PR