HiveMQ Cloud Serverless Geçiş Rehberi: MQTT İstemcilerinizi Adım Adım Taşıyın

HiveMQ Cloud Serverless geçişi büyük ölçüde bir yeniden yapılandırma projesidir: MQTT protokolü aynı kalır, ancak her istemcinin yeni bir hostname'e, yeni kimlik bilgilerine ve muhtemelen yeni bir client ID'ye ihtiyacı vardır; eski kümede bulunan her durum ise yeniden oluşturulmalıdır. Bu rehber, hedef olarak özel bir ConnectMQ broker'ı kullanarak tüm prosedürü altı adımda anlatıyor. Aynı adımlar standartlara dayalı her MQTT broker için geçerlidir.

Arka planı henüz okumadıysanız tarihler ve HiveMQ'nun 31 Aralık 2026'dan sonra neleri sildiği için HiveMQ Cloud Serverless kapanıyor yazısıyla başlayın.

1. Adım: Bağlanan Her Şeyin Envanterini Çıkarın

Listelemediğiniz bir şeyi taşıyamazsınız. HiveMQ Cloud konsolunu açın, küme hostname'inizi ve tüm erişim kimlik bilgilerini not edin, ardından her istemci türü için bir satır içeren bir tablo oluşturun:

Sessiz istemcileri unutmayın: unutulmuş bir Raspberry Pi üzerindeki Node-RED akışı, bir Grafana veya Telegraf girdisi, hostname'i koda gömülü bir mobil uygulama ya da tek bir topic'e abone olan bir iş ortağı. HiveMQ geçiş kontrol listesi bu envanterin yazdırılabilir bir sürümünü içeriyor.

2. Adım: Özellikleri Yeni Broker'la Eşleyin

Hiçbir şeyi değiştirmeden önce envanterinizi hedef planla karşılaştırın:

İki satır bir karar gerektiriyor.

Client ID'ler. HiveMQ Cloud her istemcinin kendi client ID'sini seçmesine izin verir. ConnectMQ ise client ID'yi verilen kimlik bilgilerine bağlar: bir istemci tam olarak verilen client ID'yi ya da YOUR_CLIENT_ID_sensor140 gibi bir son ek içeren varyantını kullanabilir. Her cihaza seri numarasından veya MAC adresinden türetilmiş bir son ek vermeyi planlayın. Desenler için MQTT client ID en iyi uygulamaları yazısına bakın.

İzinler. Güvenilmeyen tarafları (örneğin birbirlerinin verilerini görmemesi gereken müşterileri) ayırmak için HiveMQ topic izinlerini kullandıysanız, bunu tek bir broker üzerinde yeniden kurmaya çalışmayın. Her müşteri veya güven sınırı için bir broker kullanın ya da araya bir backend koyun.

3. Adım: Hedef Broker'ı Oluşturun

1. app.connectmq.com adresinden kaydolun. Ücretsiz Serverless planı kredi kartı gerektirmez; bu da test için idealdir.
2. En yüksek bağlantı sayınıza ek pay bırakarak boyutlandırılmış bir plan seçin. 1.000 bağlantıya kadar üretim filoları için Serverless (Paid), daha büyük veya gecikmeye duyarlı iş yükleri için Dedicated kullanın. Serverless alternatifi ve yönetilen bulut alternatifi rehberlerimiz seçim yapmanıza yardımcı olur.
3. Broker'ı oluşturun ve üretilen kullanıcı adını, parolayı ve client ID'yi kopyalayın.
4. Bu sefer broker adresini yapılandırılabilir yapın. Hostname, port, kimlik bilgileri ve client ID'yi derlenmiş firmware yerine bir yapılandırma dosyasında, provisioning servisinde veya OTA ile güncellenebilir ayarlarda saklayın. Kendi alan adınız altındaki basit bir DNS takma adı TLS için tek başına yeterli değildir; çünkü broker'ın sertifikası sağlayıcının hostname'i için verilmiştir ve hostname'i doğrulayan istemciler bu sertifikayı reddeder.

4. Adım: Gerçek Bir İstemciyle Test Edin

Üretim istemcilerini taşımadan önce temel işlevleri cihazlarınızın kullandığı kütüphanelerle kanıtlayın. TLS üzerinden mosquitto istemcileriyle:

# Terminal 1: abone ol
mosquitto_sub -h broker.connectmq.com -p 8883 --capath /etc/ssl/certs \
  -u YOUR_USERNAME -P YOUR_PASSWORD -i YOUR_CLIENT_ID_test1 \
  -t 'site1/#' -v

# Terminal 2: yayınla
mosquitto_pub -h broker.connectmq.com -p 8883 --capath /etc/ssl/certs \
  -u YOUR_USERNAME -P YOUR_PASSWORD -i YOUR_CLIENT_ID_test2 \
  -t 'site1/room1/temp' -m '{"temp":21.7}' -q 1

Ardından filonuz için önemli olan ayrıntıları test edin: QoS seviyeleri, retained mesajlar, Last Will mesajları, kullanıyorsanız kalıcı oturumlar, en büyük payload'ınıza yakın mesaj boyutları ve cihazlarınızın gerçekte kullandığı ağdan ölçülen gecikme. ConnectMQ portalındaki canlı topic gezgini her mesajı geldiği anda gösterir; bu, topic yapılarını doğrulamanın en hızlı yoludur. ESP32, Python, Node.js ve Node-RED için kod örnekleri HiveMQ sonrası MQTT istemcilerini yeniden yapılandırma yazısında.

5. Adım: Paralel Çalıştırın, Sonra Dalgalar Hâlinde Taşıyın

En güvenli geçiş, her iki broker'ı da çalışır durumda tutar ve trafiği aralarında aktarır; böylece eski broker'daki bir cihaz ile yeni broker'daki bir uygulama birbirlerinin mesajlarını görmeye devam eder. Küçük bir relay süreci bir broker'da abone olur ve diğerinde yeniden yayınlar. Eksiksiz bir relay betiğini ve dalga sırasını kesintisiz HiveMQ geçişi yazısında gösteriyoruz.

Önerilen sıra şöyle:

1. Önce tüketiciler. Veritabanlarını, kural motorlarını, Node-RED akışlarını ve dashboard'ları yeni broker'a taşıyın. Relay sayesinde eski kümedeki cihazlardan veri almaya devam ederler.
2. Pilot bir cihaz grubu. Farklı sahalardan ve firmware sürümlerinden birkaç cihaz. Bunları birkaç gün izleyin.
3. Filonun geri kalanı gruplar hâlinde, her gruptan sonra bir kontrol noktasıyla.
4. Komut üreticileri en son, kontrol ettikleri cihazlar taşındıktan sonra.

Her dalga sırasında bağlantı sayısını planınızın limitine göre izleyin. Kotayı aşarsanız MQTT 5 istemcileri 0x97 (quota exceeded) reason code'unu alır. Yükseltmeyi dalga sırasında değil, dalgadan önce yapın.

6. Adım: Geçişi Tamamlayın ve Temizleyin

HiveMQ kümesinde relay dışında hiçbir istemci bağlantısı kalmadığında:

1. Relay'i durdurun.
2. Beklenen her topic'in yeni broker'da aktif olduğunu ve retained durumun yeniden yayınlandığını doğrulayın.
3. Eski kümeden saklamak istediğiniz her şeyi, örneğin kayıtlarınız için kimlik bilgilerinin bir listesini, dışa aktarın.
4. HiveMQ'nun onu yeniden oluşturamayacağını unutmadan Serverless kümeyi silin.
5. Eski hostname'i firmware varsayılanlarından, dokümantasyondan, runbook'lardan ve secret depolarından kaldırın.

31 Aralık 2026'dan çok önce bitirmeyi hedefleyin. Birkaç haftalık bir tampon, mevsimsel ekipmanlar veya günde bir kez uyanan sensörler gibi nadiren çevrimiçi olan cihazlar için alan bırakır.

Sık Yapılan Hatalar

• Client ID çakışmaları. Aynı client ID'yi kullanan iki cihaz, hangi broker olursa olsun birbirinin bağlantısını sürekli koparır. Son ekleri benzersiz donanım tanımlayıcılarından türetin.
• Koda gömülü CA sertifikaları. Belirli bir CA paketini sabitleyen cihazlar yeni bir broker'ın sertifikasını reddedebilir. ConnectMQ bir Let's Encrypt sertifikası kullanır; ISRG Root X1 kök sertifikasının cihazın güven deposunda olduğundan emin olun. MQTT TLS yapılandırması yazısına bakın.
• Retained durumun taşındığını varsaymak. Taşınmaz. Cihazların bağlandıktan hemen sonra mevcut durumlarını retain bayrağıyla yayınlamasını sağlayın.
• Yeniden bağlanma mantığını unutmak. Düzgün bir backoff mekanizması olmayan bir cihaz, bir dalga sırasında yeni broker'ı istek yağmuruna tutabilir. Önce MQTT keep alive yazısını ve istemcinizin yeniden bağlanma ayarlarını gözden geçirin.

Sık Sorulan Sorular

HiveMQ Serverless geçişi ne kadar sürer?

Birkaç uygulama için bir gün. Firmware güncellemesi gerektiren saha cihazı filoları için haftalar planlayın: yeni firmware'i hazırlamak ve test etmek, kademeli dağıtım ve nadiren bağlanan cihazları beklemek. Son tarihin test tarihiniz olmaması için şimdi başlayın.

Cihaz firmware'ini güncellemeden geçiş yapabilir miyim?

Yalnızca hostname, kimlik bilgileri ve client ID firmware değişikliği olmadan, örneğin bir yapılandırma dosyası veya provisioning servisi aracılığıyla yapılandırılabiliyorsa. Bunlar koda derlenmişse bir OTA (over-the-air) güncellemesine ihtiyacınız var.

Topic yapımı değiştirmem gerekiyor mu?

Hayır. Topic'ler yalnızca metin dizeleridir; ConnectMQ standart wildcard'ları ve tipik IoT tasarımlarının kullandığı topic derinliklerini destekler. Dashboard'ların ve kuralların çalışmaya devam etmesi için mevcut yapınızı koruyun.

Hangi ConnectMQ planıyla başlamalıyım?

Test için ücretsiz Serverless planıyla başlayın. Üretim için 1.000 bağlantıya kadar Serverless (Paid) planını ya da izole bir kümeye ihtiyaç duyduğunuzda Dedicated Yönetilen Bulut MQTT Broker'ı seçin.