Datenlöschung bei HiveMQ Serverless: Retained Messages, Sessions und Zugangsdaten vor der Frist sichern

HiveMQ gibt an, nach dem End-of-Life-Datum von HiveMQ Cloud Serverless alle Serverless-Cluster und die darauf gespeicherten Daten endgültig zu löschen, einschließlich Retained Messages, Client-Sessions, Zugangsdaten und Berechtigungen, und einen Cluster nach der Löschung nicht wiederherstellen zu können. Nichts wird automatisch auf einen neuen Broker übertragen. Wenn ein Teil Ihres Systems von Zuständen abhängt, die im Broker gespeichert sind, müssen Sie diese vor dem 31. Dezember 2026 sichern.

Dieser Leitfaden erklärt, welche Daten gefährdet sind, wie Sie Retained Messages mit einem kurzen Skript exportieren, wie Sie Zugangsdaten und Berechtigungen dokumentieren und wie Sie Ihre Clients so gestalten, dass der neue Broker den Zustand von selbst wieder aufbaut.

Was auf Ihrem Serverless-Cluster liegt

Nachrichten, die weder retained noch für eine Session eingereiht sind, werden nie gespeichert. Dort gibt es also nichts zu exportieren: Die Historie Ihrer Telemetrie liegt in Ihrer eigenen Datenbank, nicht im Broker. Falls Sie Telemetrie heute nirgends speichern, ist jetzt ein guter Moment, einen Subscriber hinzuzufügen, der sie in eine Datenbank schreibt – etwa in einen Historian oder eine Zeitreihendatenbank.

Retained Messages mit Python exportieren

Retained Messages lassen sich nur lesen, indem man sie abonniert. Ein Client, der # abonniert, erhält jede Retained Message, die er sehen darf, markiert mit retain=True. Das folgende Skript sammelt sie einige Sekunden lang und schreibt sie in eine JSON-Datei, wobei binäre Payloads wie Sparkplug B als Base64 kodiert werden. Es verwendet 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"   # Ihr HiveMQ-Serverless-Hostname
USER, PASSWORD = "YOUR_HIVEMQ_USERNAME", "YOUR_HIVEMQ_PASSWORD"

retained = {}

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

def on_message(client, userdata, msg):
    if msg.retain:  # nur Nachrichten, die auf dem Broker gespeichert sind
        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)          # Retained Messages kommen direkt nach dem Abonnieren an
client.loop_stop()
client.disconnect()

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

Führen Sie es mit Zugangsdaten aus, die Abonnementrechte für alle Topics haben. Sind Ihre Berechtigungen aufgeteilt, führen Sie es einmal pro Zugangsdatensatz aus. Bei sehr großen Topic-Bäumen erhöhen Sie die Wartezeit, bis die Anzahl nicht mehr wächst.

Retained Messages auf dem neuen Broker wiederherstellen

Sobald Ihr neuer Broker existiert, veröffentlichen Sie jede gespeicherte Nachricht erneut mit gesetztem Retain-Flag:

# 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"{len(retained)} Retained Topics wiederhergestellt")

QoS ist hier auf 1 begrenzt, weil der kostenlose Serverless-Tarif QoS bis 1 unterstützt; ab Serverless (Paid) können Sie QoS 2 beibehalten. Prüfen Sie die Topics anschließend im Live-Topic-Explorer von ConnectMQ. Vorsicht bei Retained Messages, die Befehle sind: Wird ein alter Befehl „Ventil öffnen" wiederhergestellt, kann er eine Aktion auslösen, sobald sich ein Gerät neu verbindet – in einer Anlage ein echtes Sicherheitsrisiko. Prüfen Sie den Export und verwerfen Sie alles, was nicht erneut abgespielt werden darf. Hintergründe zu diesem Verhalten finden Sie unter MQTT Retained Messages.

Persistente Sessions lassen sich nicht exportieren

Der Session-Zustand, also die Abonnements eines Clients und seine Warteschlange nicht zugestellter Nachrichten, ist intern im Broker gespeichert. Es gibt keine MQTT-Operation, um ihn zu exportieren. Gehen Sie stattdessen so vor:

1. Stellen Sie sicher, dass Clients bei jeder Verbindung erneut abonnieren, auch wenn sie eine persistente Session nutzen. Die meisten Bibliotheken tun das, wenn Sie im Connect-Callback abonnieren.
2. Ziehen Sie Clients in einem Zeitraum um, in dem sie online sind, sodass ihre Warteschlangen leer sind.
3. Legen Sie auf dem neuen Broker ein passendes Session Expiry Interval fest. Siehe MQTT Persistent Session und MQTT Session Expiry Interval.

Zugangsdaten und Berechtigungen dokumentieren

Passwörter können Sie nicht exportieren, aber Sie sollten das Zugriffsmodell dokumentieren, bevor die Konsole verschwindet:

• Erfassen Sie jeden Namen eines Zugangsdatensatzes und was ihn nutzt (Gerätegruppe, Dienst, Partner).
• Halten Sie seine Berechtigungen fest: auf welche Topic-Filter er veröffentlichen oder welche er abonnieren darf.
• Legen Sie die Zuordnung auf dem neuen Broker fest. Bei ConnectMQ gibt jeder Broker einen Benutzernamen, ein Passwort und eine Client-ID aus; Clients können die Client-ID mit einem _suffix verwenden, um mehrere Verbindungen mit einem Satz Zugangsdaten zu betreiben. Wo Sie sich auf Topic-Berechtigungen verlassen haben, um nicht vertrauenswürdige Parteien zu trennen, nutzen Sie separate Broker pro Vertrauensgrenze.

Speichern Sie die neuen Zugangsdaten in einem Secrets Manager, nicht in einer Tabellenkalkulation. Der Leitfaden zum sicheren Speichern von MQTT-Zugangsdaten auf Geräten behandelt die Speicherung auf dem Gerät.

Zustand auf jedem Broker selbstheilend machen

Die beste langfristige Lösung ist, Geräte für ihren eigenen Zustand verantwortlich zu machen. Wenn sich ein Gerät verbindet, sollte es sofort seinen aktuellen Status, seine Konfiguration und seine Firmware-Version mit gesetztem Retain-Flag veröffentlichen und eine Last-Will-Nachricht setzen, damit Abonnenten erfahren, wenn es unerwartet offline geht. Dann verliert ein Broker-Wechsel, ein Neustart oder eine Migration nie länger als einen Verbindungszyklus lang Zustand. In einem Unified Namespace (UNS) nach ISA-95 ist genau dieses Muster die Grundlage dafür, dass jede Ebene stets den aktuellen Zustand von Linie und Maschine sieht. Das Muster erklären wir unter MQTT Last Will and Testament.

Häufig gestellte Fragen

Löscht HiveMQ meine Daten am 1. Januar 2027?

HiveMQ gibt an, nach dem End-of-Life-Datum alle Serverless-Cluster und ihre Daten endgültig zu löschen und einen gelöschten Cluster nicht wiederherstellen zu können. Exportieren Sie, was Sie brauchen, vor dem 31. Dezember 2026.

Kann ich meine Nachrichtenhistorie aus HiveMQ Serverless exportieren?

Der Broker speichert keine Historie gewöhnlicher Nachrichten, sondern nur Retained Messages und eingereihte Session-Nachrichten. Die Telemetrie-Historie muss aus Ihrer eigenen Datenbank oder Ihrem eigenen Speicher stammen.

Sehen wiederhergestellte Retained Messages für Abonnenten anders aus?

Nein. Eine Retained Message, die mit demselben Topic und derselben Payload wiederhergestellt wurde, wird neuen Abonnenten genau wie zuvor zugestellt, mit gesetztem Retain-Flag.

Sollte ich meinen HiveMQ-Cluster selbst löschen?

Erst wenn alle Clients auf dem neuen Broker laufen und Sie exportiert haben, was Sie brauchen. HiveMQ kann einen gelöschten Cluster nicht wiederherstellen.