HiveMQ, HiveMQ Cloud Serverless'ın kapanış tarihinden sonra tüm Serverless kümeleri ve üzerlerindeki verileri (retained mesajlar, istemci oturumları, erişim kimlik bilgileri ve izinler dahil) kalıcı olarak sileceğini ve silinen bir kümeyi geri yükleyemeyeceğini belirtiyor. Hiçbir şey otomatik olarak yeni bir broker'a taşınmıyor. Sisteminizin herhangi bir parçası broker'da saklanan duruma bağlıysa, bu durumu 31 Aralık 2026'dan önce kayıt altına almanız gerekiyor.
Bu rehber hangi verilerin risk altında olduğunu, retained mesajları kısa bir betikle nasıl dışa aktaracağınızı, kimlik bilgilerini ve izinleri nasıl belgeleyeceğinizi ve istemcilerinizi yeni broker'ın durumu kendiliğinden yeniden oluşturacağı şekilde nasıl tasarlayacağınızı açıklıyor.
Serverless Kümenizde Neler Bulunuyor?
| Veri | Nedir? | Kaybolursa etkisi |
|---|---|---|
| Retained mesajlar | Her topic için saklanan son mesaj; yeni abonelere hemen iletilir | Cihazlar yeniden yayın yapana kadar dashboard'lar ve sonradan bağlanan uygulamalar hiçbir şey göstermez; yapılandırma topic'leri kaybolur |
| İstemci oturumları | Kalıcı oturumla bağlanan istemcilerin abonelikleri ve kuyruktaki QoS 1/2 mesajları | Çevrimdışı istemciler kendileri için kuyruğa alınmış mesajları kaçırır |
| Erişim kimlik bilgileri | Kümenin erişim yönetimindeki kullanıcı adları ve parolalar | Her istemcinin yeni kimlik bilgileri alması gerekir |
| İzinler | Hangi kimlik bilgisinin hangi topic'lere yayın yapabileceği veya abone olabileceği | Erişim modelinizin yeni broker'da yeniden tasarlanması gerekir |
| Küme URL'si | hivemq.cloud hostname'i |
Her istemcinin yeni bir hostname'e ihtiyacı vardır |
Retained olmayan ve bir oturum için kuyruğa alınmamış mesajlar hiç saklanmaz; dolayısıyla orada dışa aktarılacak bir şey yoktur: telemetri geçmişiniz broker'da değil, kendi veritabanınızda bulunur. Bugün telemetriyi hiçbir yerde saklamıyorsanız, onu bir veritabanına yazan bir abone eklemek için şimdi iyi bir zaman.
Retained Mesajları Python ile Dışa Aktarın
Retained mesajları okumanın tek yolu onlara abone olmaktır. # topic'ine abone olan bir istemci, görmeye yetkili olduğu her retained mesajı retain=True bayrağıyla alır. Aşağıdaki betik bunları birkaç saniye boyunca toplar ve Sparkplug B gibi ikili payload'ları base64 olarak kodlayarak bir JSON dosyasına yazar. paho-mqtt 2.x kullanır:
# pip install "paho-mqtt>=2.0"
import base64, json, ssl, time
import paho.mqtt.client as mqtt
HOST = "YOUR_CLUSTER.s1.eu.hivemq.cloud" # HiveMQ Serverless hostname'iniz
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: # yalnızca broker'da saklanan mesajlar
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 mesajlar abone olunduktan hemen sonra gelir
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")
Betiği tüm topic'lerde abone olma izni olan bir kimlik bilgisiyle çalıştırın. İzinleriniz bölünmüşse her kimlik bilgisi için bir kez çalıştırın. Çok büyük topic ağaçlarında, sayı artmayı bırakana kadar bekleme süresini uzatın.
Retained Mesajları Yeni Broker'a Geri Yükleyin
Yeni broker'ınız hazır olduğunda saklanan her mesajı retain bayrağıyla yeniden yayınlayın:
# 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")
Ücretsiz Serverless planı QoS 1'e kadar desteklediği için burada QoS 1 ile sınırlandırılmıştır; Serverless (Paid) ve üzerinde QoS 2'yi koruyabilirsiniz. Ardından topic'leri ConnectMQ canlı topic gezgininde kontrol edin. Komut niteliğindeki retained mesajlara dikkat edin: eski bir "vanayı aç" komutunu geri yüklemek, bir cihaz yeniden bağlandığında bir eylemi tetikleyebilir. Dışa aktarılan veriyi gözden geçirin ve yeniden oynatılmaması gereken her şeyi çıkarın. Bu davranışın arka planı MQTT retained mesajlar yazısında.
Kalıcı Oturumlar Dışa Aktarılamaz
Oturum durumu, yani bir istemcinin abonelikleri ve teslim edilmemiş mesaj kuyruğu, broker'ın içinde tutulur. Bunu dışa aktaracak bir MQTT işlemi yoktur. Bunun yerine:
- İstemcilerin kalıcı oturum kullansalar bile her bağlantıda yeniden abone olduğundan emin olun. Çoğu kütüphane, connect callback'i içinde abone olursanız bunu yapar.
- İstemcileri çevrimiçi oldukları bir dönemde taşıyın; böylece kuyrukları boş olur.
- Yeni broker'da uygun bir session expiry interval ayarlayın. MQTT kalıcı oturum ve MQTT oturum sona erme süresi yazılarına bakın.
Kimlik Bilgilerini ve İzinleri Belgeleyin
Parolaları dışa aktaramazsınız, ancak konsol ortadan kalkmadan önce erişim modelini belgelemelisiniz:
- Her kimlik bilgisinin adını ve onu neyin kullandığını (cihaz grubu, servis, iş ortağı) listeleyin.
- İzinlerini kaydedin: hangi topic filtrelerine yayın yapabileceğini veya abone olabileceğini.
- Yeni broker'daki eşlemeye karar verin. ConnectMQ'da her broker bir kullanıcı adı, parola ve client ID üretir; istemciler tek bir kimlik bilgisi setiyle birden fazla bağlantı çalıştırmak için client ID'yi
_suffixile kullanabilir. Güvenilmeyen tarafları ayırmak için topic izinlerine dayandığınız yerlerde her güven sınırı için ayrı broker'lar kullanın.
Yeni kimlik bilgilerini bir tabloda değil, bir secrets manager'da saklayın. Cihazlarda MQTT kimlik bilgilerini güvenceye alma rehberi cihaz tarafındaki saklamayı ele alıyor.
Durumu Her Broker'da Kendiliğinden Onarılabilir Hâle Getirin
Uzun vadede en iyi çözüm, cihazları kendi durumlarından sorumlu kılmaktır. Bir cihaz bağlandığında mevcut durumunu, yapılandırmasını ve firmware sürümünü hemen retain bayrağıyla yayınlamalı ve beklenmedik şekilde çevrimdışı olduğunda abonelerin bunu öğrenmesi için bir Last Will mesajı ayarlamalıdır. Böylece bir broker değişikliği, yeniden başlatma veya geçiş, durumu hiçbir zaman tek bir bağlantı döngüsünden daha uzun süre kaybettirmez. Bu desen için MQTT Last Will and Testament yazısına bakın.
Sık Sorulan Sorular
HiveMQ verilerimi 1 Ocak 2027'de silecek mi?
HiveMQ, kapanış tarihinden sonra tüm Serverless kümeleri ve verilerini kalıcı olarak sileceğini ve silinen bir kümenin geri yüklenemeyeceğini belirtiyor. İhtiyacınız olan her şeyi 31 Aralık 2026'dan önce dışa aktarın.
HiveMQ Serverless mesaj geçmişimi dışa aktarabilir miyim?
Broker sıradan mesajların geçmişini tutmaz; yalnızca retained mesajları ve kuyruktaki oturum mesajlarını saklar. Telemetri geçmişi kendi veritabanınızdan veya depolamanızdan gelmelidir.
Geri yüklenen retained mesajlar abonelere farklı mı görünür?
Hayır. Aynı topic ve payload ile geri yüklenen bir retained mesaj, yeni abonelere retain bayrağı ayarlı olarak tam olarak eskisi gibi iletilir.
HiveMQ kümemi kendim mi silmeliyim?
Yalnızca tüm istemciler yeni broker'da çalıştıktan ve ihtiyacınız olan her şeyi dışa aktardıktan sonra. HiveMQ silinen bir kümeyi yeniden oluşturamaz.
