Bir veri toplama sisteminin “yedekli olması”, kesintide veri kaybetmeyeceği anlamına gelmez. Çoğu tesis bunu, bir ağ kesintisinden sonra üretim raporunda boşluk gördüğünde öğrenir. Üç kavram, üç farklı soruyu yanıtlar ve her birine ayrı tasarım gerekir.
Yedeklilik: hizmet sürsün. Tamponlama: kesinti sırasında veri kaybolmasın. Kurtarma: arızadan sonra sistem ve veri normale dönsün.
Üç kavram, üç soru
| Yedeklilik | Tamponlama | Kurtarma | |
|---|---|---|---|
| Soru | Bir bileşen arızalanırsa hizmet sürer mi? | Hedefe ulaşılamazken veri kaybolur mu? | Arıza sonrası ne kadar sürede, hangi veriyle ayağa kalkarız? |
| Mekanizma | İkinci bileşen devralır (failover) | Yerel kuyruğa yaz, bağlantı gelince sırayla gönder (store-and-forward) | Yedekten geri yükleme, yeniden oynatma, mutabakat |
| Örnek | İki Kepware Server örneği arasında otomatik geçiş (RedundancyMaster) | Toplayıcıda disk tabanlı kuyruk; broker veya veritabanına yeniden gönderim | Proje yedeği, veritabanı yedeği, boşluk doldurma |
| Sınır | Geçiş sırasında kısa veri boşluğu olabilir | Tampon dolarsa veri kaybolur | Yedek, yedeğin alındığı ana kadar günceldir |
Tamponlama nasıl çalışır?
Toplayıcı (edge) veriyi kaynakta zaman damgalar. Hedefe ulaşabiliyorsa doğrudan iletir. Ulaşamazsa kayıtları yerel bir kuyruğa (tercihen disk tabanlı, böylece yeniden başlatmadan etkilenmez) yazar; bağlantı geldiğinde kayıtları sırayla yeniden gönderir. Hedef tarafta kimlik ve zaman damgası, aynı kaydın iki kez yazılmasını engeller.
Tampon ne kadar büyük olmalı?
Tampon boyutu iki şeyin çarpımıdır: beklenen en uzun kesinti ve veri hızı. Örnek hesap: 2.000 etiket, saniyede 1 güncelleme, kayıt başına yaklaşık 40 bayt → saniyede ~80 KB, saatte ~288 MB. Sekiz saatlik bir kesintiye dayanmak için ~2,3 GB ayırmak ve üzerine güvenlik payı eklemek gerekir. Değişime göre gönderim (deadband) hacmi azaltır. Kesintinin ne kadar süreceği, ağ ve sistem mimarisinden bağımsız bir iş kararıdır: “En fazla ne kadar veri boşluğu kabul edilebilir?”
Tasarım adımları
- Kabul edilebilir kaybı tanımlayın. Hangi veri kayıpsız olmalı (parti sonucu, enerji sayacı), hangisi yaklaşık olabilir (trend)?
- Kritik veri için kaynakta tamponlama sağlayın. Bazı toplayıcılar (ör. bazı MQTT ve veritabanı yazıcıları) store-and-forward seçeneği sunar; yapılandırmayı belgelerinden doğrulayın.
- Yinelenenleri önleyin. Hedefte kimlik + zaman damgası ile tekil anahtar kullanın (PLC verisini SQL’e aktarma).
- Yedekliliği ayrıca düşünün. Kritik toplama sunucusu için ikinci örnek ve otomatik geçiş; ama geçiş sırasında oluşabilecek boşluğu tamponlama ile kapatın.
- Kurtarmayı prova edin. Yedekten geri yükleme süresini ve sonucunu periyodik olarak test edin; yazılı plan yetmez.
- İzleyin. Tampon doluluğu, kuyruk uzunluğu ve yeniden gönderim hızı için uyarı üretin.
Sık yapılan hatalar
- “Sunucumuz yedekli, yani veri kaybı olmaz” varsayımı.
- Tamponu yalnızca bellekte tutmak; yeniden başlatmada kayıt kaybolur.
- Yeniden gönderimde yinelenen kayıtlar yaratmak.
- Tampon dolduğunda ne olacağını tanımlamamak (en eskiyi mi atar, yenisini mi?).
- Zaman damgasını yeniden gönderim anında atamak; olay zamanı kaybolur (veri kalitesi ve zaman damgası).
Bu ilkeler OPC Router akışları, Kepware Server ve MQTT tabanlı mimariler için de geçerlidir (UNS). Entegrasyon kabul testinde kesinti senaryosu mutlaka sınanmalıdır (kabul testleri).
Sık sorulan sorular
Yedekli iki sunucu varsa tampona gerek var mı?
Evet. Geçiş sırasında veya iki sunucuya birden ulaşılamadığında oluşabilecek boşluğu tamponlama kapatır; ikisi birbirini tamamlar.
Tampon dolarsa ne olur?
Politikaya bağlıdır: en eski kayıtlar atılabilir ya da yeni kayıtlar reddedilebilir. Hangisinin kabul edilebilir olduğu iş kararıdır ve baştan yazılmalıdır.
Kurtarma ile yedekleme aynı mı?
Hayır. Yedekleme veriyi saklar; kurtarma, o yedekten sistemi çalışır hale getirme sürecidir ve prova edilmelidir.
