[Questions] [3.13.7] exchange bindings not visible in all admin instances of cluster

[bilak]

Community Support Policy

• I have read RabbitMQ's Community Support Policy

RabbitMQ version used

3.13.7 or older

How is RabbitMQ deployed?

Other

Steps to reproduce the behavior in question

I just can't find the info anywhere. We have cluster of 3 nodes. When I connect to admin instances 0 and 1 and check the exchange details there are no bindings of queues. If I connect to admin instance 2, I can see those bindings. I'm just wondering if this is intended behaviour or there's some kind of bug. Version of rabbitmq is 3.13.7. Exchange is durable and ha-all

[michaelklishin]

@bilak this is a known problem with topic exchanges with Mnesia.

See "A whole category of issues with binding inconsistency are addressed with the stabilization
of Khepri" in the 4.0 release notes and upgrade to 4.1.1, then enable Khepri.

[bilak]

@michaelklishin does this also apply to fanout exchanges or only topic? Does it affect only displaying the metadata or overall performance/functionality?
We are little bit stuck since we use 3.x rabbitmq integrated through spring boot...trying to understand what we can do.

[michaelklishin]

Read the change log and upgrade. 3.13.x is out of community support.

Spring Boot will happily work with 4.x. As will a Java client from 2013.

[michaelklishin]

For those ignoring the fact that 3.13.x has been out of community support since Sep 2024 and that there won't be any new publicly produced releases: the workaround is to rebind everything that's bound to the exchange in question.

Alternate Exchanges (configured with a policy) and Exchange-to-Exchange bindings can do that in a way that won't disrupt routing. Build an "alternative route" with them while you re-create the affected bindings, then remove the temporary AE policy and any E2E bindings that were necessary.

Our team strongly recommends upgrading to 4.1 and enabling Khepri. That's the only fundamental solution.

With a 0.99 probability your applications won't have to change, unless you explicitly depend on classic queue mirroring that's been formally deprecated for four years now, and recommended against for some 5-6 years.