RabbitMQ upgrade 3.8.23 -> 3.13.7

[AyoubFNIZI]

Community Support Policy

• I have read RabbitMQ's Community Support Policy
• I run RabbitMQ 4.x, the only series currently covered by community support
• I promise to provide all relevant information (versions, logs from all nodes, rabbitmq-diagnostics output, detailed reproduction steps)

RabbitMQ version used

other (please specify)

Erlang version used

26.0.x

Operating system (distribution) used

windows server 2019

How is RabbitMQ deployed?

Windows binary package

rabbitmq-diagnostics status output

N/A

Logs from node 1 (with sensitive values edited out)

N/A

Logs from node 2 (if applicable, with sensitive values edited out)

N/A

Logs from node 3 (if applicable, with sensitive values edited out)

N/A

rabbitmq.conf

N/A

Steps to deploy RabbitMQ cluster

N/A

Steps to reproduce the behavior in question

N/A

advanced.config

N/A

Application code

N/A

Kubernetes deployment file

N/A

What problem are you trying to solve?

Hello everyone,

First off, thank you for the incredible work you're doing!

I’m new to RabbitMQ and I'm currently working on upgrading a three-node RabbitMQ cluster. Unfortunately the current setup is running RabbitMQ 3.8.23 with Erlang 24.1, and we’re looking to upgrade to RabbitMQ 3.13.7 with Erlang 26.2.

From the documentation, I understand that a rolling upgrade requires several intermediary versions.. This process can be quite lengthy and seems to reduce the main benefit of rolling upgrades — maintaining cluster availability during the upgrade since I should install major version of Erlang (mixed Erlang major versions in a cluster could impact inter-node communication)

Given these limitations, I’m considering a blue-green deployment for the upgrade. My main concern is around data migration and its consistency once the green cluster is ready to take over.

basically it is possible to import the backed up definitions from blue to green and with federation we can duplicate, in real time, messages received on the bleu to the green cluster to prepare the producers / consumers switch.

Are there any potential issues or caveats I should be aware of in the case of this huge upgrade-jump ?
I’m mainly concerned with ensuring data consistency and minimal downtime during the switch.

Many thanks !!

[michaelklishin]

RabbitMQ 3.13.x is out of community support.

Blue/Green Upgrades use queue federation to transfer messages where consumers are (so, if they are only available in the new cluster, they will be transferred there).

If your applications in the original cluster always churn topology, there is no solution to that in the OSS RabbitMQ edition, you will have to move those apps first and/or potentially import definitions a few times.

In Tanzu RabbitMQ (the commercial edition) there is a feature that continuously replicates the schema to remote clusters, called Schema Definition Sync (SDS).