RabbitMQ 4.3.6: actualización práctica sin sorpresas

Qué versión es y por qué merece una revisión operativa

Al consultar la documentación oficial el 29 de septiembre de 2026, RabbitMQ 4.3.6 aparece como la última revisión disponible de la rama 4.3. La tabla de releases del proyecto fecha su publicación el 16 de septiembre de 2026 y marca el fin del soporte comunitario de la rama 4.3 para el 30 de noviembre de 2026. Es una maintenance release, no una promesa de que cualquier clúster pueda actualizarse sin cambios ni una certificación de seguridad para todas las instalaciones.

Si necesitas repasar conceptos básicos del broker, el artículo RabbitMQ: qué es, cómo funciona y cuándo deberías utilizarlo cubre esa introducción. Esta pieza parte de ese contexto y se concentra en mantenimiento, compatibilidad y actualización operativa.

La revisión corrige comportamientos que pueden notarse durante una operación normal: reconciliación de miembros de las quorum queues, limpieza de bindings al eliminar exchanges, comparación de duraciones en Streams y límites de canales en conexiones directas usadas por Shovel y Federation. También añade límites explícitos para transacciones AMQP 0-9-1 y un retraso opcional para los listeners de clientes.

La pregunta útil no es «¿puedo instalar el paquete?», sino «¿mi ruta, mi backend de metadatos, mis plugins y mis clientes siguen siendo compatibles cuando el primer nodo vuelva a estar disponible?».

La matriz de compatibilidad que debes cerrar primero

Antes de tocar un nodo, registra la versión de RabbitMQ y Erlang/OTP de cada miembro, el sistema operativo y el origen de los paquetes. El objetivo es evitar que el gestor de paquetes instale una combinación distinta de la que probaste.

• Ruta de RabbitMQ: para llegar a 4.3.x, la ruta soportada es 4.2.x → 4.3.x. Un origen 3.13.x requiere 4.2.x como paso intermedio, salvo la excepción de Khepri descrita abajo. Si ya operas 4.3.x, actualiza dentro de esa rama según la revisión soportada; no retrocedas a 4.2.x como supuesto paso de actualización.
• Erlang/OTP: RabbitMQ 4.3.6 requiere como mínimo Erlang/OTP 27.0. La matriz de compatibilidad de la documentación muestra 28.x como máximo para la fila 4.3.6. La política también indica que Erlang 28 tiene soporte completo y que Erlang 29 empieza a estar soportado desde 4.3.6, pero advierte que no todos los paquetes lo declaran todavía. Por eso Erlang 29 no debe tratarse como una opción homogénea: valida el paquete concreto, el sistema operativo y la mezcla temporal de versiones antes del rollout.
• Uniformidad del clúster: usa la misma versión mayor de Erlang en todos los nodos salvo durante la ventana estrictamente necesaria de actualización. RabbitMQ puede rechazar combinaciones incompatibles de protocolos internos, y mantener mezclas durante más tiempo aumenta la superficie de diagnóstico.
• Feature flags: lista las feature flags y confirma que las estables exigidas por la ruta ya están activadas antes del primer nodo. Tras completar la actualización, habilita las flags estables introducidas por la versión destino cuando hayas comprobado el estado de todo el clúster.
• Khepri: identifica si el clúster usa Khepri o Mnesia y no asumas que son intercambiables durante un rolling upgrade. Una vez realizada la migración de Mnesia a Khepri, volver a Mnesia no está soportado; no cambies el backend como parte del rolling upgrade. Un clúster RabbitMQ 3.13.x con Khepri habilitado no puede actualizarse in-place a 4.x; para ese caso la documentación indica una migración blue-green a un clúster nuevo. En una instalación que sí tiene una ruta soportada, Khepri sigue siendo una razón para revisar la matriz de Erlang y el comportamiento de los nodos mezclados, no para improvisar un cambio de backend durante la actualización.

Una comprobación de inventario puede combinar la salida de rabbitmq-diagnostics cluster_status, rabbitmq-diagnostics status, el listado de feature flags y rabbitmq-plugins list con el inventario de paquetes del sistema. Los comandos exactos y sus permisos dependen de cómo se instaló RabbitMQ; el punto importante es guardar la salida por nodo antes de iniciar el cambio.

Cambios de 4.3.6 que pueden afectar tu operación

No todas las correcciones son visibles para todos los clientes. Estas son las que justifican buscar dependencias antes del rollout:

Área	Qué corrige 4.3.6	Qué comprobar
Quorum queues	La reconciliación continua de miembros podía añadir más réplicas que el objetivo configurado.	Miembros actuales, líder, objetivo de réplicas y sincronizaciones pendientes; la release no repara por sí sola una topología ya desordenada.
Exchanges	Eliminar un exchange podía dejar bindings que lo apuntaban como destino; también se corrigen casos de auto-delete, colas transitorias y eliminación de vhosts.	Declaraciones y limpieza que tu automatización repite, especialmente en entornos efímeros.
Streams	x-max-age se compara como duración: redeclarar 1D después de 24h deja de fallar por argumentos no equivalentes.	Clientes o scripts que redeclaran Streams con distintas representaciones de la misma duración. No extrapoles esto a todos los argumentos.
Shovel y Federation	Las conexiones directas aplican channel_max_per_node igual que las conexiones de red.	Número de canales por nodo, cantidad de enlaces y margen disponible durante la reconexión.
Transacciones AMQP 0-9-1	channel_tx_message_max limita a 10.000 por defecto las publicaciones que un canal conserva en una transacción abierta. Excederlo produce precondition_failed.	Productores transaccionales, tamaño de lote, tamaño de mensaje y tratamiento de excepciones. No aumentes el límite sin medir memoria y patrón de confirmación.
Arranque	listeners.startup_delay puede retrasar los listeners el número de segundos configurado para evitar conexiones demasiado tempranas.	Health checks, backoff y reconexión del cliente. El retraso no sustituye esos mecanismos.

Las notas de la release no sustituyen las pruebas de tu topología. Si tu despliegue no usa Streams, transacciones abiertas o esos plugins, elimina esos casos de la matriz y concentra la validación en los contratos que sí existen.

Staging: prueba los contratos que realmente usas

Replica en un entorno de staging la versión de RabbitMQ, Erlang/OTP, plugins, configuración y tipo de metadatos que tendrá producción. Fija las versiones de las imágenes o paquetes; una etiqueta flotante puede convertir una prueba repetible en otra combinación.

La matriz mínima debería cubrir:

1. Topología y recuperación. Declara exchanges, colas, bindings, quorum queues y Streams con los mismos argumentos que utiliza la aplicación. Detén y recupera un nodo de prueba, comprueba la elección de líderes y espera a que las réplicas terminen de sincronizarse antes de medir.
2. Flujo de mensajes. Publica con confirms, consume, fuerza redeliveries y verifica el comportamiento cuando el cliente pierde la conexión. Comprueba que los consumidores conocen hosts alternativos y que no dependen de que el nodo detenido vuelva de inmediato.
3. Streams. Redeclara una configuración equivalente de x-max-age usando las representaciones que aparecen en tus clientes. Registra si el SDK normaliza la duración o compara literalmente los argumentos antes de 4.3.6.
4. Transacciones. Si existe AMQP 0-9-1 transaccional, prueba lotes por debajo y por encima de 10.000 publicaciones con mensajes representativos. La segunda prueba debe verificar la excepción precondition_failed, la reapertura del canal y la decisión de la aplicación; no debe convertirse en una recomendación automática de subir el límite.
5. Shovel/Federation y canales. Genera la cantidad normal de enlaces y canales, mide reconexiones y observa el límite por nodo. Un enlace directo puede alcanzar ahora un límite que antes no se aplicaba de la misma forma.
6. Gestión y observabilidad. Ejercita los endpoints de Management API y los probes de salud que usa tu plataforma. Registra latencia, conexiones, canales, tasa de publicación/consumo, mensajes no confirmados, alarmas y errores de protocolo.

Rolling upgrade nodo a nodo

RabbitMQ recomienda el rolling upgrade cuando existe una ruta soportada. En cada nodo, el orden operativo es detenerlo de forma controlada, actualizar RabbitMQ y Erlang si corresponde, iniciarlo y observar la recuperación antes de pasar al siguiente. Durante todo el proceso conserva capacidad para conexiones reubicadas, reelección de líderes y sincronización de réplicas.

Antes de comenzar, detén el rollout si existe cualquiera de estas condiciones:

• alarmas activas o crecimiento sostenido de memoria/disco;
• sincronización en curso de réplicas de quorum queues o Streams;
• carga excepcional que no permita distinguir el efecto del cambio;
• feature flags estables pendientes o una ruta de versiones no soportada;
• un nodo con una versión de Erlang fuera de la matriz del paquete elegido;
• clientes sin hosts alternativos, backoff o reconexión comprobable.

Después de arrancar cada nodo, espera a que el health check sea satisfactorio, confirma que volvió al clúster y revisa líderes, miembros, conexiones, canales, alarmas y tasas de mensajes. Un nodo «arriba» no equivale a un clúster recuperado: la aplicación puede seguir acumulando mensajes o reintentando conexiones.

Define por adelantado el criterio de pausa. Por ejemplo: réplicas que no sincronizan dentro del umbral operativo, alarmas persistentes, aumento anómalo de reconexiones, límites de canales alcanzados, errores repetidos precondition_failed, degradación de latencia o respuestas de API incompatibles. Si aparece uno, congela el siguiente nodo y conserva la evidencia; no continúes para «terminar la tanda».

Recuperación: volver no significa hacer downgrade in-place

RabbitMQ no admite oficialmente downgrades: no están probados y no deben tomarse como un procedimiento de recuperación. Un rolling upgrade tampoco ofrece una reversión automática. Si hay que recuperar el servicio, aplica el procedimiento aprobado para tu plataforma: conservar el clúster anterior o sus paquetes, configuración, definiciones, credenciales de automatización y datos de diagnóstico; y decidir si la recuperación requiere restauración o migración.

No presentes un downgrade in-place como el reverso simétrico de la actualización. Las estructuras de datos, feature flags, backend de metadatos y versiones de Erlang pueden impedirlo o dejar un clúster en un estado que no sea seguro. Cuando el riesgo exige poder cambiar de dirección, blue-green es la opción que RabbitMQ documenta como más segura: despliega un clúster nuevo, sincroniza metadatos según el diseño, mueve consumidores y productores de forma controlada y conserva el clúster anterior hasta cerrar la ventana. Ese rollback operativo no es un downgrade del clúster actualizado: es un cambio de tráfico hacia el entorno anterior. Consume infraestructura adicional y requiere un plan explícito para migrar o drenar mensajes.

Para un 3.13.x con Khepri habilitado, blue-green no es un lujo operativo: la documentación indica que esa combinación no tiene upgrade in-place a 4.x. Trátalo como migración a un clúster nuevo y valida el movimiento de metadatos y mensajes por separado.

Fuentes primarias

• RabbitMQ Release Information: versión 4.3.6, fecha de release y fechas de soporte.
• RabbitMQ Server 4.3.6 — release notes: cambios de core, Streams, Shovel/Federation, límites de canales, transacciones y listeners.startup_delay.
• Erlang Version Requirements: matriz RabbitMQ/Erlang, mínimo 27.0, soporte de Erlang 28 y el matiz de Erlang 29.
• Upgrading RabbitMQ: rutas soportadas, feature flags, rolling, blue-green y advertencias para Khepri.
• Rolling (in-place) Upgrade: pasos nodo a nodo y comprobaciones de salud.
• Khepri FAQ: incompatibilidad de un 3.13.x con Khepri habilitado frente a un upgrade a 4.x.