Message duplication in federated queue #4605
Unanswered
AntonAleksandrov13
asked this question in
Questions
Replies: 1 comment
-
RabbitMQ queues, federated or not, do not perform any kind of deduplication. There is no mandatory message ID in any of the protocols RabbitMQ supports. Internally used message IDs are not universally unique. Such "writes on both sides" setup is guaranteed to cause confusion and our Blue/Green deployment doc guide does not assume it. Because federated queues can move messages from a remote cluster locally |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Good morning,
I am running two rabbitmq clusters(A and B respectively). My goals is to migrate fully from cluster A to cluster B with no downtime as production greatly depends on a consistent message flow. Hence, I am trying Green-Blue strategy.
I have setup bi-directional federated queues for all virtual hosts in both clusters like this:
On cluster B:
rabbitmqctl set_parameter --vhost=vhost1 federation-upstream blue '{"uri":"amqp://A", "ack-mode": "on-publish"}'
rabbitmqctl set_policy --apply-to queues blue-migration ".*" '{"federation-upstream":"blue"}'
rabbitmqctl set_parameter --vhost=vhost2 federation-upstream blue2 '{"uri":"amqp://A", "ack-mode": "on-publish"}'
rabbitmqctl set_policy --apply-to queues blue-migration2 ".*" '{"federation-upstream":"blue2"}'
On cluster A:
rabbitmqctl set_parameter --vhost=vhost1 federation-upstream green '{"uri":"amqp://B", "ack-mode": "on-publish"}'
rabbitmqctl set_policy --apply-to queues green-migration ".*" '{"federation-upstream":"green"}'
rabbitmqctl set_parameter --vhost=vhost2 federation-upstream green2'{"uri":"amqp://B", "ack-mode": "on-publish"}'
rabbitmqctl set_policy --apply-to queues green-migration2 ".*" '{"federation-upstream":"green2"}'
Our migration will not be fast, so my idea was to allow migrated producers write to cluster B. Respectively, not-migrated consumers can still use cluster A. Hence, I have encountered the following case:

I wonder if this can be avoided. Thanks in advance!
Beta Was this translation helpful? Give feedback.
All reactions