HiveMQ indique qu'après la date de fin de vie de HiveMQ Cloud Serverless, il supprime définitivement tous les clusters Serverless et les données qu'ils contiennent, y compris les messages retenus, les sessions clients, les identifiants d'accès et les permissions, et qu'il ne peut pas restaurer un cluster après sa suppression. Rien n'est transféré automatiquement vers un nouveau broker. Si une partie de votre système dépend d'un état stocké dans le broker, vous devez le récupérer avant le 31 décembre 2026.
Ce guide explique quelles données sont menacées, comment exporter les messages retenus avec un court script, comment documenter les identifiants et les permissions, et comment concevoir vos clients pour que le nouveau broker reconstruise l'état de lui-même.
Ce que contient votre cluster Serverless
| Donnée | De quoi il s'agit | Conséquence en cas de perte |
|---|---|---|
| Messages retenus | Le dernier message stocké pour chaque topic, délivré immédiatement aux nouveaux abonnés | Les tableaux de bord et les applications qui se connectent plus tard n'affichent rien tant que les appareils n'ont pas republié ; les topics de configuration disparaissent |
| Sessions clients | Abonnements et messages QoS 1/2 en file des clients qui se connectent avec une session persistante | Les clients hors ligne manquent les messages qui leur étaient destinés |
| Identifiants d'accès | Noms d'utilisateur et mots de passe de la gestion des accès du cluster | Chaque client doit recevoir de nouveaux identifiants |
| Permissions | Quel identifiant peut publier ou s'abonner sur quels topics | Votre modèle d'accès doit être repensé sur le nouveau broker |
| URL du cluster | Le nom d'hôte hivemq.cloud |
Chaque client a besoin d'un nouveau nom d'hôte |
Les messages qui ne sont ni retenus ni mis en file pour une session ne sont jamais stockés : il n'y a donc rien à exporter de ce côté. L'historique de votre télémétrie se trouve dans votre propre base de données, pas dans le broker. Si vous ne stockez la télémétrie nulle part aujourd'hui, c'est le bon moment pour ajouter un abonné qui l'écrit dans une base de données.
Exporter les messages retenus avec Python
La seule façon de lire les messages retenus est de s'y abonner. Un client abonné à # reçoit tous les messages retenus qu'il est autorisé à voir, marqués retain=True. Le script ci-dessous les collecte pendant quelques secondes et les écrit dans un fichier JSON, en encodant en base64 les payloads binaires comme Sparkplug B. Il utilise 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" # votre nom d'hôte 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: # uniquement les messages stockés sur le 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) # les messages retenus arrivent juste après l'abonnement
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")
Exécutez-le avec un identifiant qui a le droit de s'abonner à tous les topics. Si vos permissions sont réparties, exécutez-le une fois par identifiant. Pour des arborescences de topics très volumineuses, augmentez le temps d'attente jusqu'à ce que le nombre de topics cesse d'augmenter.
Restaurer les messages retenus sur le nouveau broker
Une fois votre nouveau broker créé, republiez chaque message stocké avec le 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")
La QoS est plafonnée à 1 ici, car le plan Serverless gratuit prend en charge la QoS jusqu'à 1 ; à partir de Serverless (Paid), vous pouvez conserver la QoS 2. Vérifiez ensuite les topics dans l'explorateur de topics en direct de ConnectMQ. Attention aux messages retenus qui sont des commandes : restaurer une ancienne commande « ouvrir la vanne » peut déclencher une action lorsqu'un appareil se reconnecte. Relisez l'export et retirez tout ce qui ne doit pas être rejoué. Le contexte de ce comportement est expliqué dans Messages retenus MQTT.
Les sessions persistantes ne peuvent pas être exportées
L'état de session, c'est-à-dire les abonnements d'un client et sa file de messages non délivrés, est interne au broker. Aucune opération MQTT ne permet de l'exporter. À la place :
- Assurez-vous que les clients se réabonnent à chaque connexion, même lorsqu'ils utilisent une session persistante. La plupart des bibliothèques le font si vous vous abonnez dans le callback de connexion.
- Migrez les clients pendant une période où ils sont en ligne, afin que leurs files soient vides.
- Sur le nouveau broker, définissez un intervalle d'expiration de session approprié. Voir Session persistante MQTT et Intervalle d'expiration de session MQTT.
Documenter les identifiants et les permissions
Vous ne pouvez pas exporter les mots de passe, mais vous devez documenter le modèle d'accès avant que la console ne disparaisse :
- Listez chaque nom d'identifiant et ce qui l'utilise (groupe d'appareils, service, partenaire).
- Notez ses permissions : sur quels filtres de topics il peut publier ou s'abonner.
- Décidez de la correspondance sur le nouveau broker. Sur ConnectMQ, chaque broker délivre un nom d'utilisateur, un mot de passe et un client ID ; les clients peuvent utiliser le client ID avec un
_suffixpour ouvrir plusieurs connexions avec un même jeu d'identifiants. Là où vous vous appuyiez sur les permissions de topics pour séparer des parties non fiables, utilisez des brokers distincts pour chaque périmètre de confiance.
Stockez les nouveaux identifiants dans un gestionnaire de secrets, pas dans un tableur. Le guide sécuriser les identifiants MQTT sur les appareils traite du stockage côté appareil.
Rendez l'état auto-réparable, quel que soit le broker
La meilleure solution à long terme consiste à rendre les appareils responsables de leur propre état. Lorsqu'un appareil se connecte, il doit publier immédiatement son statut actuel, sa configuration et sa version de firmware avec le flag retain, et définir un message Last Will pour que les abonnés sachent quand il se déconnecte de manière inattendue. Ainsi, un changement de broker, un redémarrage ou une migration ne fait jamais perdre l'état plus longtemps qu'un cycle de connexion. Voir MQTT Last Will and Testament pour ce modèle.
Questions fréquentes
HiveMQ supprime-t-il mes données le 1er janvier 2027 ?
HiveMQ indique qu'après la date de fin de vie, il supprime définitivement tous les clusters Serverless et leurs données, et qu'un cluster supprimé ne peut pas être restauré. Exportez ce dont vous avez besoin avant le 31 décembre 2026.
Puis-je exporter l'historique de mes messages HiveMQ Serverless ?
Le broker ne conserve pas d'historique des messages ordinaires ; il ne stocke que les messages retenus et les messages de session en file. L'historique de télémétrie doit provenir de votre propre base de données ou de votre propre stockage.
Les messages retenus restaurés apparaîtront-ils différemment aux abonnés ?
Non. Un message retenu restauré avec le même topic et le même payload est délivré aux nouveaux abonnés exactement comme avant, avec le flag retain positionné.
Dois-je supprimer moi-même mon cluster HiveMQ ?
Seulement une fois que tous vos clients tournent sur le nouveau broker et que vous avez exporté ce dont vous avez besoin. HiveMQ ne peut pas recréer un cluster supprimé.
