Este documento detalla el proceso de migración de una configuración existente de RocketMQ de un modelo multi-master a un modelo multi-master con múltiples slaves. La motivación principal detrás de esta migración es la obsolescencia del hardware del clúster de producción de RocketMQ y un incidente previo de caída del sistema. Además, se busca mejorar la arquitectura de red separando entornos de producción, desarrollo y pruebas.

Pruebas Funcionales y de Clúster del Modo Multi-Master con Múltiples Slaves

Las pruebas funcionales y de clúster para el nuevo modo multi-master con múltiples slaves se han completado satisfactoriamente. Los resultados confirman la viabilidad y robustez de la configuración propuesta.

Pasos de Migración, Problemas Encontrados y Soluciones

1. Actualización de la Tabla de Rutas de Topics en Todos los Brokers

Este paso es crucial debido a deficiencias en la configuración inicial de RocketMQ, donde la distribución de rutas de topics no era óptima. Si un topic no recibe un número mínimo de mensajes al ser creado, su ruta puede no propagares a todos los brokers, afectando el balanceo de carga y la disponibilidad si el broker que contiene la ruta falla.

Existen dos métodos para resolver esto:

1. Modificación a través de la consola de RocketMQ: Esta opción ha sido validada en producción.
2. Reemplazo del archivo Topics.json: Copie el archivo Topics.json de otro broker (generalmente el primer broker del clúster) al directorio config dentro de la ruta raíz de almacenamiento (storePathRootDir) y reinicie el servicio. Esta solución también ha sido verificada en producción.

Nota: El archivo Topics.json suele obtenerse de la primera máquina del clúster de MQ. Por ejemplo, si los brokers de producción son 158.7, 158.8 y 158.9, la máquina 158.7 normalmente contendrá la información de ruta para todos los topics.

2. Modificación Secuencial del Modo del Clúster de Producción

Se modificará el modo del clúster de MQ de producción de multi-master a multi-master con múltiples slaves, configurando el modo de escritura dual síncrona y el刷盘 (flush) síncrono. La elección del modo de刷盘 debe basarse en la carga de trabajo de MQ (síncrono para cargas bajas, asíncrono para cargas altas). Este paso no presenta riesgos significativos.

3. Desactivación de un Master y Espera de Consumo por parte del Slave

Siga estos pasos al desmantelar un master:

1. Notificar a NameServer: Informe a NameServer que el broker está a punto de desconectarse para evitar que se le envíen más mensajes. Utilice el siguiente comando: ``` sh mqadmin wipeWritePerm -b <brokerName> -n <namesrvAddr>

   
    Comando de ejemplo: ```
   sh mqadmin wipeWritePerm -b broker-a -n 172.16.158.7:9876
         sh mqadmin wipeWritePerm -b broker-a -n 172.16.158.8:9876
         sh mqadmin wipeWritePerm -b broker-a -n 172.16.158.9:9876
   

   (Ejecute este comando por cada NameServer. Aunque el comando soporta múltiples NameServers separados por ';', puede generar errores).

2. Apagar el Broker: Espere 1-2 minutos (un poco más si hay mensajes diferidso que el slave necesita consumir) y luego apague el broker: ``` sh mqshutdown broker

4. Modificación de la Configuración de IP y Modo

Modifique la dirección IP del master o apáguelo. Luego, actualice la dirección IP del slave a la del master y configure sus archivos de configuración al modo master. El reinicio aplicará los cambios.

Problema Encontrado: Al intentar que un slave actúe como master, se observan múltiples advertencias en los logs como "WARN ScheduleMessageTimerThread - findMapedFileByOffset offset not ..." y la escritura de mensajes falla.

Solución: Elimine todos los archivos del directorio especificado por storePathRootDir en el servidor actual y reinicie el servicio. Luego, copie el archivo Topics.json de otro servidor y reinicie nuevamente. (Esta solución fue validada en producción, aunque podría existir un método más simple).

5. Modificación de los Brokers Restantes

Repita los pasos 3 y 4 para los otros dos brokers del clúster.

6. Adición de Slaves para los Nuevos Masters

Proceda a añadir los slaves correspondientes a los nuevos masters.