Migración desde HiveMQ

Borrado de datos de HiveMQ Serverless: guarda mensajes retenidos, sesiones y credenciales antes de la fecha límite

Cuando se retire HiveMQ Cloud Serverless, los mensajes retenidos, las sesiones de cliente, las credenciales de acceso y los permisos se eliminarán de forma permanente. Esta guía muestra cómo exportar el estado retenido, documentar las credenciales y reconstruirlo todo en tu nuevo broker MQTT.

Mensajes MQTT retenidos y datos de sesión exportados desde un clúster HiveMQ Serverless antes de su eliminación y restaurados en un nuevo broker
Pruébalo en tu propio broker MQTTConsigue un broker MQTT privado y gestionado con el plan Free y empieza con ejemplos de código listos para usar.
Pruébalo gratis Ejemplos de código Sin tarjeta

HiveMQ indica que, después de la fecha de fin de vida de HiveMQ Cloud Serverless, eliminará de forma permanente todos los clústeres Serverless y los datos que contienen, incluidos mensajes retenidos, sesiones de cliente, credenciales de acceso y permisos, y que no puede restaurar un clúster una vez eliminado. Nada se traslada automáticamente a un nuevo broker. Si alguna parte de tu sistema depende de estado almacenado en el broker, tienes que capturarlo antes del 31 de diciembre de 2026.

Esta guía explica qué datos están en riesgo, cómo exportar los mensajes retenidos con un script breve, cómo documentar credenciales y permisos, y cómo diseñar tus clientes para que el nuevo broker reconstruya el estado por sí solo.

Qué vive en tu clúster Serverless

Dato Qué es Impacto si se pierde
Mensajes retenidos El último mensaje almacenado por topic, entregado de inmediato a los nuevos suscriptores Los dashboards y las apps que se conectan más tarde no muestran nada hasta que los dispositivos vuelven a publicar; los topics de configuración desaparecen
Sesiones de cliente Suscripciones y mensajes QoS 1/2 en cola de los clientes que se conectan con sesión persistente Los clientes desconectados pierden los mensajes que tenían en cola
Credenciales de acceso Usuarios y contraseñas en la gestión de accesos del clúster Cada cliente debe recibir nuevas credenciales
Permisos Qué credencial puede publicar o suscribirse a qué topics Tu modelo de acceso debe rediseñarse en el nuevo broker
URL del clúster El hostname hivemq.cloud Cada cliente necesita un nuevo hostname

Los mensajes que no son retenidos ni están en cola para una sesión nunca se almacenan, así que ahí no hay nada que exportar: el histórico de tu telemetría vive en tu propia base de datos, no en el broker. Si hoy no guardas la telemetría en ningún sitio, es un buen momento para añadir un suscriptor que la escriba en una base de datos.

Exporta los mensajes retenidos con Python

La única forma de leer los mensajes retenidos es suscribirse a ellos. Un cliente que se suscribe a # recibe todos los mensajes retenidos que tiene permiso para ver, marcados con retain=True. El siguiente script los recoge durante unos segundos y los escribe en un archivo JSON, codificando en base64 los payloads binarios como los de Sparkplug B. Usa paho-mqtt 2.x:

# pip install "paho-mqtt>=2.0"
import base64, json, ssl, time
import paho.mqtt.client as mqtt

HOST = "YOUR_CLUSTER.s1.eu.hivemq.cloud"   # tu hostname de HiveMQ Serverless
USER, PASSWORD = "YOUR_HIVEMQ_USERNAME", "YOUR_HIVEMQ_PASSWORD"

retained = {}

def on_connect(client, userdata, flags, reason_code, properties):
    print("Connected:", reason_code)
    client.subscribe("#", qos=1)

def on_message(client, userdata, msg):
    if msg.retain:  # solo los mensajes almacenados en el broker
        retained[msg.topic] = {
            "qos": msg.qos,
            "payload_b64": base64.b64encode(msg.payload).decode(),
        }

client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id="retained-export-1",
                     protocol=mqtt.MQTTv5)
client.username_pw_set(USER, PASSWORD)
client.tls_set(cert_reqs=ssl.CERT_REQUIRED)
client.on_connect = on_connect
client.on_message = on_message
client.connect(HOST, 8883)
client.loop_start()
time.sleep(10)          # los mensajes retenidos llegan justo después de suscribirse
client.loop_stop()
client.disconnect()

with open("retained-export.json", "w") as f:
    json.dump(retained, f, indent=2)
print(f"Saved {len(retained)} retained topics")

Ejecútalo con una credencial que tenga permiso de suscripción sobre todos los topics. Si tus permisos están repartidos, ejecútalo una vez por credencial. Para árboles de topics muy grandes, aumenta el tiempo de espera hasta que el recuento deje de crecer.

Restaura los mensajes retenidos en el nuevo broker

Cuando tu nuevo broker exista, vuelve a publicar cada mensaje almacenado con el flag retain:

# pip install "paho-mqtt>=2.0"
import base64, json, ssl, time
import paho.mqtt.client as mqtt

client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id="YOUR_CLIENT_ID_restore",
                     protocol=mqtt.MQTTv5)
client.username_pw_set("YOUR_USERNAME", "YOUR_PASSWORD")
client.tls_set(cert_reqs=ssl.CERT_REQUIRED)
client.connect("broker.connectmq.com", 8883)
client.loop_start()

with open("retained-export.json") as f:
    retained = json.load(f)

for topic, item in retained.items():
    payload = base64.b64decode(item["payload_b64"])
    client.publish(topic, payload, qos=min(item["qos"], 1), retain=True).wait_for_publish()

client.loop_stop()
client.disconnect()
print(f"Restored {len(retained)} retained topics")

Aquí el QoS se limita a 1 porque el plan Serverless gratuito admite QoS hasta 1; en Serverless (Paid) y superiores puedes mantener QoS 2. Después, revisa los topics en el explorador de topics en vivo de ConnectMQ. Ten cuidado con los mensajes retenidos que son comandos: restaurar un antiguo comando "abrir válvula" puede desencadenar una acción cuando un dispositivo se reconecta. Revisa la exportación y descarta todo lo que no deba reproducirse. Tienes más contexto sobre este comportamiento en mensajes retenidos de MQTT.

Las sesiones persistentes no se pueden exportar

El estado de sesión, es decir, las suscripciones de un cliente y su cola de mensajes no entregados, es interno del broker. No existe ninguna operación MQTT para exportarlo. En su lugar:

  1. Asegúrate de que los clientes se vuelven a suscribir en cada conexión, incluso cuando usan sesión persistente. La mayoría de las librerías lo hacen si te suscribes en el callback de conexión.
  2. Mueve los clientes en un momento en que estén conectados, para que sus colas estén vacías.
  3. En el nuevo broker, configura un intervalo de expiración de sesión adecuado. Consulta sesión persistente de MQTT e intervalo de expiración de sesión de MQTT.

Documenta credenciales y permisos

No puedes exportar las contraseñas, pero deberías documentar el modelo de acceso antes de que desaparezca la consola:

  • Enumera cada nombre de credencial y qué la usa (grupo de dispositivos, servicio, partner).
  • Anota sus permisos: en qué filtros de topic puede publicar o suscribirse.
  • Decide la correspondencia en el nuevo broker. En ConnectMQ, cada broker emite un usuario, una contraseña y un client ID; los clientes pueden usar el client ID con un _sufijo para abrir varias conexiones con un mismo conjunto de credenciales. Donde dependías de permisos de topic para separar a partes que no confían entre sí, usa brokers separados por cada frontera de confianza.

Guarda las nuevas credenciales en un gestor de secretos, no en una hoja de cálculo. La guía sobre cómo proteger las credenciales MQTT en los dispositivos trata el almacenamiento en el lado del dispositivo.

Haz que el estado se recupere solo en cualquier broker

La mejor solución a largo plazo es que los dispositivos sean responsables de su propio estado. Cuando un dispositivo se conecta, debería publicar inmediatamente su estado actual, su configuración y su versión de firmware con el flag retain, y configurar un mensaje Last Will para que los suscriptores sepan cuándo se desconecta de forma inesperada. Así, un cambio de broker, un reinicio o una migración nunca pierden el estado durante más de un ciclo de conexión. Consulta MQTT Last Will and Testament para ver el patrón.

Preguntas frecuentes

¿Borrará HiveMQ mis datos el 1 de enero de 2027?

HiveMQ indica que, después de la fecha de fin de vida, elimina de forma permanente todos los clústeres Serverless y sus datos, y que un clúster eliminado no se puede restaurar. Exporta lo que necesites antes del 31 de diciembre de 2026.

¿Puedo exportar el histórico de mensajes de HiveMQ Serverless?

El broker no guarda un histórico de los mensajes normales; solo almacena los mensajes retenidos y los mensajes en cola de las sesiones. El histórico de telemetría tiene que salir de tu propia base de datos o almacenamiento.

¿Verán los suscriptores distintos los mensajes retenidos restaurados?

No. Un mensaje retenido restaurado con el mismo topic y payload se entrega a los nuevos suscriptores exactamente igual que antes, con el flag retain activado.

¿Debo eliminar yo mismo mi clúster de HiveMQ?

Solo cuando todos los clientes funcionen en el nuevo broker y hayas exportado lo que necesitas. HiveMQ no puede volver a crear un clúster eliminado.

Artículos relacionados

Alternativa a HiveMQ Serverless: pásate al broker MQTT serverless de ConnectMQ Cloud

Los usuarios de HiveMQ Cloud Serverless Free y Pay As You Go que quieren la misma experiencia sin servidores pueden pasarse al broker MQTT serverless de ConnectMQ Cloud. Descubre los planes, límites, endpoints y herramientas integradas, y cómo conectar tu primer dispositivo en minutos.

6 min de lectura

Todos los artículos →

Tu broker MQTT privado, a unos pocos clics

Crea una cuenta, obtén las credenciales de tu broker y conecta tu primer dispositivo, sin servidores que instalar, parchear ni escalar.