HiveMQ Cloud Serverless'tan hizmeti kesintiye uğratmadan ayrılmanın en güvenli yolu, iki broker'ı bir süre paralel çalıştırmak ve mesajları aralarında aktarmaktır. Böylece cihazlar ve uygulamalar grup grup taşınabilir; hâlâ HiveMQ'da olan bir cihaz, çoktan taşınmış bir uygulamayla konuşmaya devam eder. Bu makale bu relay'i nasıl kuracağınızı, mesaj döngülerinden nasıl kaçınacağınızı ve istemcileri 31 Aralık 2026 son tarihinden önce dalgalar hâlinde nasıl taşıyacağınızı gösteriyor.
Neden Bir Relay Gerekiyor?
Ne HiveMQ Cloud Serverless ne de ConnectMQ gibi yönetilen bir bulut broker, bulut tarafında sizin için başka bir broker'a köprü kurar. Çözüm, sizin çalıştırdığınız küçük bir relay sürecidir: her iki broker'a da sıradan bir MQTT istemcisi olarak bağlanır, bir taraftaki seçili topic'lere abone olur ve bunları diğer tarafta yeniden yayınlar. Yalnızca bir istemci olduğu için standartlara dayalı her broker ile çalışır ve özel izin gerektirmez.
devices (still on HiveMQ) --> HiveMQ Serverless --relay--> ConnectMQ --> moved consumers
moved command senders --> ConnectMQ --relay--> HiveMQ Serverless --> devices
Sahada zaten Mosquitto çalıştırıyorsanız, bridge özelliği aynı işi görebilir; Mosquitto'yu bulut MQTT broker'a taşıma ve Mosquitto bridge yapılandırması yazılarına bakın.
Döngü Sorunu ve Ondan Nasıl Kaçınılır?
Relay site1/# topic'ini hem HiveMQ'dan ConnectMQ'ya hem de ConnectMQ'dan HiveMQ'ya aktarırsa, her mesaj sonsuza kadar ileri geri sekip durur. Döngüleri tasarım yoluyla önleyin:
- Yöne göre aktarın. Telemetri bir yönde (eskiden yeniye), komutlar diğer yönde (yeniden eskiye) akar. Aynı topic filtresini her iki yönde aktarmayın.
- Aboneliklerde MQTT 5 No Local kullanın; böylece relay aynı broker üzerinde kendi yayınlarını almaz.
- Aktarılan mesajları işaretleyin.
relayed=1gibi bir MQTT 5 user property kullanın ve bunu zaten taşıyan mesajları atın.
Aşağıdaki betik bu üçünü de uygular.
Python ile Eksiksiz Bir Relay
Bu relay her iki tarafta da paho-mqtt 2.x ve MQTT 5 kullanır. Telemetri ve durum mesajları HiveMQ'dan ConnectMQ'ya, komutlar ise ConnectMQ'dan HiveMQ'ya aktarılır.
# pip install "paho-mqtt>=2.0"
import os, ssl
import paho.mqtt.client as mqtt
from paho.mqtt.packettypes import PacketTypes
from paho.mqtt.properties import Properties
from paho.mqtt.subscribeoptions import SubscribeOptions
# Yön başına topic filtreleri (aynı filtreyi asla iki yönde birden listelemeyin)
OLD_TO_NEW = ["site1/+/telemetry", "site1/+/status"]
NEW_TO_OLD = ["site1/+/cmd"]
def make_client(client_id, user, password):
c = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id=client_id, protocol=mqtt.MQTTv5)
c.username_pw_set(user, password)
c.tls_set(cert_reqs=ssl.CERT_REQUIRED)
c.reconnect_delay_set(min_delay=1, max_delay=60)
return c
old = make_client("relay-old-1", os.environ["HIVEMQ_USER"], os.environ["HIVEMQ_PASSWORD"])
new = make_client(os.environ["CMQ_CLIENT_ID"] + "_relay", os.environ["CMQ_USER"], os.environ["CMQ_PASSWORD"])
def is_relayed(msg):
props = getattr(msg, "properties", None)
return any(k == "relayed" for k, _ in (getattr(props, "UserProperty", None) or []))
def forward(target):
def on_message(client, userdata, msg):
if is_relayed(msg):
return
props = Properties(PacketTypes.PUBLISH)
props.UserProperty = [("relayed", "1")]
target.publish(msg.topic, msg.payload, qos=min(msg.qos, 1), retain=msg.retain, properties=props)
return on_message
def subscriber(filters):
def on_connect(client, userdata, flags, reason_code, properties):
print("connected:", reason_code, "subscribing to", filters)
opts = SubscribeOptions(qos=1, noLocal=True)
for f in filters:
client.subscribe(f, options=opts)
return on_connect
old.on_connect, old.on_message = subscriber(OLD_TO_NEW), forward(new)
new.on_connect, new.on_message = subscriber(NEW_TO_OLD), forward(old)
old.connect(os.environ["HIVEMQ_HOST"], 8883)
new.connect("broker.connectmq.com", 8883)
new.loop_start()
old.loop_forever()
Betiği her iki broker'a da yakın, güvenilir bir host üzerinde (örneğin küçük bir bulut VM'inde veya bir container'da), kimlik bilgilerini ortam değişkenlerinde tutarak çalıştırın. Relay'in ücretsiz Serverless planında çalışması için QoS 1 ile sınırlandırılmıştır; akışlarınız gerektiriyorsa Serverless (Paid) ve üzerinde 2'ye yükseltin. Retain bayrakları korunur; bu yüzden HiveMQ'da yayınlanan retained durum mesajları ConnectMQ'da da retained olarak görünür.
İki pratik not:
- Relay her broker'da bir bağlantı olarak sayılır. Yeni planı boyutlandırırken onu da hesaba katın.
- Onu bir üretim bileşeni gibi izleyin. Relay durursa, taşınmış ve taşınmamış istemciler arasındaki mesajlar da durur. Onu systemd altında veya bir container yeniden başlatma politikasıyla çalıştırın.
Dalga Planı
İstemcileri her veri akışının çalışmaya devam edeceği bir sırayla taşıyın.
| Dalga | Kim taşınıyor? | Neden bu sırayla? |
|---|---|---|
| 0 | Relay başlar | Her iki broker da aynı telemetriyi ve komutları görür |
| 1 | Backend tüketicileri: veritabanları, kural motorları, Node-RED, dashboard'lar | Cihaz verilerini relay üzerinden alırlar |
| 2 | Farklı sahalardan ve firmware sürümlerinden pilot bir cihaz grubu | Sınırlı riskle gerçek dünyada doğrulama |
| 3'ten N'ye | Kalan cihazlar, saha veya ürün hattına göre gruplar hâlinde | Kontrol noktalarıyla kontrollü dağıtım |
| Son | Komut üreticileri, ardından relay durdurulur | Cihazlar zaten yeni broker'dadır |
Her dalgadan sonra şunları kontrol edin:
- ConnectMQ dashboard'undaki bağlantı sayısı taşınan istemci sayısıyla eşleşiyor.
- Beklenen topic'ler canlı topic gezgininde görünüyor.
$SYS/broker/connection/{clientId}/stateüzerindeki istemci başına bağlantı durumu taşınan cihazları çevrimiçi gösteriyor.- Taşınan hiçbir istemci hâlâ HiveMQ'ya bağlanmıyor (HiveMQ konsolunu kontrol edin).
- Bağlantı sayısı plan limitleri içinde kalıyor; bir kota aşılırsa MQTT 5 istemcileri
0x97alır.
Geri Dönüş
Eski küme hâlâ çalışırken her dalga, önceki bağlantı ayarları geri yüklenerek geri alınabilir. Son dalga tamamlanana kadar eski ayarları provisioning sisteminizde erişilebilir tutun. Geçişi aralığın son günlerine bırakmamanın ana nedeni budur: 31 Aralık 2026'dan sonra geri dönülecek bir yer kalmaz.
Geçiş Kontrol Listesi
- Tüm cihazlar ve uygulamalar yeni broker'da çalışıyor.
- HiveMQ konsolu relay dışında hiçbir istemci bağlantısı göstermiyor.
- Retained durum yeni broker'da mevcut; cihazlar tarafından yeniden yayınlanmış veya dışa aktarılan veriden geri yüklenmiş. HiveMQ Serverless veri silme yazısına bakın.
- Relay'i durdurun ve HiveMQ'da yeniden ortaya çıkan herhangi bir istemci için bir gün boyunca izleyin.
- HiveMQ Serverless kümesini silin ve eski hostname'i yapılandırmadan, firmware varsayılanlarından ve dokümantasyondan kaldırın.
Uçtan uca süreç için HiveMQ Serverless geçiş rehberine bakın. Relay'i bugün app.connectmq.com adresindeki ücretsiz bir broker'a karşı kurup test edebilirsiniz.
Sık Sorulan Sorular
HiveMQ Cloud doğrudan ConnectMQ'ya köprü kurabilir mi?
Bulut tarafında hayır. Yukarıdaki betik gibi bir relay istemcisini ya da kendi altyapınızda, her iki broker'a da normal bir MQTT istemcisi olarak bağlanan bir Mosquitto bridge'i çalıştırın.
Cihazlar geçişi fark edecek mi?
Taşınan cihazlar, ayarları değiştiğinde kısa bir yeniden bağlanma yaşar. Henüz taşınmamış cihazlar hiçbir değişiklik görmez; çünkü relay onların verilerini taşınmış uygulamalara akıtmaya devam eder.
Relay gecikme ekler mi?
Fazladan bir atlama ekler; nerede çalıştığına bağlı olarak genellikle birkaç milisaniye ile onlarca milisaniye arasında. Onu her iki broker'a da yakın konumlandırın ve geçiş tamamlandığında kaldırın.
Relay QoS 1 mi yoksa QoS 2 mi kullanmalı?
QoS 1 iyi bir varsayılandır ve her ConnectMQ planında çalışır. Tüketicilerin QoS 1'in izin verdiği ara sıra oluşan kopyaları ele aldığından emin olun. QoS 2'yi yalnızca kopyaların kabul edilemez olduğu ve planınızın desteklediği yerlerde kullanın.
