Dosya Senkronizasyonu: İki Sunucu Arasında Veri Tutarlılığı

Çok sunuculu yapılarda dosya tutarlılığı, nesne depolamaya geçiş, senkronizasyon riskleri ve doğrulama yöntemleri. Dosya Senkronizasyonu: İki Sunucu Arasında…

Dosya Senkronizasyonu: İki Sunucu Arasında Veri Tutarlılığı
İçindekiler
  1. Sorunun Kaynağı
  2. Çözüm Yaklaşımları
  3. Çift Yönlü Senkronizasyonun Riski
  4. Ağ Dosya Sistemi
  5. Senkronizasyon Araçları
  6. Nesne Depolamaya Geçiş
  7. Dikkat Edilecekler
  8. Tutarlılığı Doğrulamak
  9. Sonuç
  10. Sıkça Sorulan Sorular (SSS)
  11. İkinci sunucuda dosyalar neden görünmüyor?
  12. En iyi çözüm hangisi?
  13. Çift yönlü senkronizasyon neden riskli?
  14. Diğer sunucuda bozuk dosyalar oluşuyor?

Dosya Senkronizasyonu: İki Sunucu Arasında Veri Tutarlılığı

İkinci sunucuyu devreye aldınız ve trafiği ikiye böldünüz. Kullanıcı bir dosya yükledi, ilk sunucuya düştü. Sonra sayfayı yeniledi, ikinci sunucuya düştü ve dosyası kayboldu.

Bu yazı, çok sunuculu yapılarda dosya tutarlılığını ele alıyor.

Sorunun Kaynağı

Yatay ölçeklemenin en sık atlanan tarafı budur:

  • Kod her sunucuda aynıdır.
  • Veritabanı ortaktır.
  • Ama dosyalar yereldir.

Üçüncü madde tüm sorunu üretir: veritabanı ortak olduğu için kayıt her sunucuda görünür, ama o kayda ait dosya yalnızca yüklendiği sunucuda vardır — sonuç, var olan ama bulunamayan dosyalardır.

Bu tutarsızlık en çok görsel yüklemelerde ve belge eklerinde fark edilir.

Çözüm Yaklaşımları

Yöntem Değerlendirme
Nesne depolama En temiz çözüm
Ağ dosya sistemi Kolay ama tek arıza noktası
Çift yönlü senkronizasyon Çakışma riski
Tek yönlü kopyalama Sınırlı senaryolar
Oturumu sabitlemek Geçici çare

Birinci satır sorunu kökten çözer: dosyaları sunucudan tamamen çıkarıp bir nesne depolamaya taşımak, hangi sunucunun isteği aldığını önemsiz hâle getirir — senkronizasyon ihtiyacı ortadan kalkar.

Beşinci satır ise sorunu çözmez, erteler. Kullanıcıyı hep aynı sunucuya yönlendirmek dosyayı bulunabilir kılar ama o sunucu çöktüğünde her şey kaybolur.

Üçüncü satır ise en riskli olanıdır ve sonraki bölümün konusudur.

Çift Yönlü Senkronizasyonun Riski

İki sunucunun da yazabildiği bir yapıda:

  1. Aynı dosya iki yerde değişebilir.
  2. Hangisinin kazanacağı belirsizdir.
  3. Silme işlemi geri gelebilir.

Üçüncü madde en sinsi davranıştır: bir sunucuda silinen dosya, senkronizasyon yönü nedeniyle diğer sunucudan geri kopyalanabilir ve dosya hiç silinmemiş gibi görünür.

Bu, kullanıcı verisi silme taleplerinde ciddi bir uyum sorunu üretir.

İkinci madde ise sessiz veri kaybına yol açar. Zaman damgasına göre karar veren bir senkronizasyon, saatleri bir saniye kaymış iki sunucuda yanlış dosyayı kazandırabilir.

Bu nedenle çift yönlü senkronizasyon, yalnızca aynı dosyanın iki yerde değişmeyeceğinden emin olunan senaryolarda kullanılmalıdır.

Ağ Dosya Sistemi

Pratik ama dikkat gerektiren bir çözümdür:

  • Tek bir kaynak vardır. Tutarlılık sorunu yok.
  • Kod değişikliği gerekmez.
  • Ağ gecikmesi eklenir.
  • Sunucu çökerse hepsi etkilenir.

Üçüncü madde performansı doğrudan etkiler: yerel diskte mikrosaniyelerle ölçülen bir dosya işlemi, ağ üzerinden milisaniyelere çıkar — çok sayıda küçük dosya okuyan uygulamalarda bu fark belirgin bir yavaşlama üretir.

Bu nedenle ağ dosya sistemi, büyük ve az sayıda dosya için uygun, çok sayıda küçük dosya için sorunludur.

Dördüncü madde ise mimari bir zayıflıktır. Yatay ölçekleme yaparken yeni bir tek arıza noktası yaratmış olursunuz.

Senkronizasyon Araçları

Yaklaşım Uygunluk
Zamanlanmış kopyalama Gecikme kabul edilebilirse
Dosya sistemi olayı dinleme Anında senkronizasyon
Uygulama seviyesinde çoğaltma Tam kontrol

Üçüncü satır en güvenilir olanıdır: dosyayı yükleyen kodun onu iki hedefe birden yazması, dosya sistemi seviyesindeki tüm belirsizlikleri ortadan kaldırır ve başarısızlık anında hata verir.

Dosya sistemi tabanlı senkronizasyon ise sessizce başarısız olabilir ve kimse fark etmez.

İkinci satır ise ölçekte sorun çıkarır. Milyonlarca dosya içeren bir dizini izlemek, önemli miktarda bellek tüketir.

Birinci satır ise en basit olanıdır ve yedekleme amaçlı kullanımda yeterlidir.

Nesne Depolamaya Geçiş

Mevcut bir uygulamayı taşımak kademeli yapılabilir:

  1. Yeni yüklemeleri nesne depolamaya yönlendirin.
  2. Eski dosyaları arka planda taşıyın.
  3. Okumada önce yeni yeri deneyin.
  4. Bulamazsa eski yerden okuyun.
  5. Taşıma bitince yedek yolu kaldırın.

Üçüncü ve dördüncü maddeler geçişi kesintisiz kılar: okuma tarafında iki kaynağı sırayla denemek, taşıma devam ederken bile hiçbir dosyanın kaybolmamasını sağlar.

Bu geri dönüş mantığı, taşıma tamamlandıktan sonra kaldırılmalıdır; aksi hâlde her bulunamayan dosya için gereksiz ikinci bir sorgu yapılır.

İkinci madde ise trafik dışı saatlerde çalıştırılmalıdır.

Dikkat Edilecekler

  • Dosya adlarında çakışma olmasın.
  • İzinler her yerde tutarlı olsun.
  • Geçici dosyaları senkronize etmeyin.
  • Senkronizasyon trafiğini sınırlayın.

Üçüncü madde ciddi bir hata kaynağıdır: yükleme sırasında oluşan yarım dosyaların senkronize edilmesi, diğer sunucuda bozuk dosyaların görünmesine yol açar.

Doğru yaklaşım, dosyayı geçici bir adla yazıp tamamlandığında son adına taşımaktır. Senkronizasyon yalnızca tamamlanmış dosyaları görür.

Dördüncü madde ise ağ etkisini yönetir. Büyük bir senkronizasyon, kullanıcı trafiğini bekletebilir.

İkinci madde ise erişim hatalarını önler. Bir sunucuda okunabilir olan dosya diğerinde okunamıyorsa, kullanıcı rastgele hata alır.

Tutarlılığı Doğrulamak

Kontrol Yöntem
Dosya sayısı İki tarafta karşılaştırın
Toplam boyut Hızlı gösterge
Rastgele örnekleme İçerik doğrulama
Veritabanı ile eşleştirme Öksüz kayıt tespiti

Dördüncü satır en değerli kontroldür ve iki yönlü çalışır: veritabanında kaydı olup dosyası olmayan kayıtlar kullanıcıya kırık bağlantı gösterir; dosyası olup kaydı olmayanlar ise sessizce disk tüketir.

Bu iki listeyi düzenli çıkarmak, hem hatayı hem israfı ortaya koyar.

Birinci satır ise en hızlı ilk kontroldür ve büyük bir tutarsızlığı anında gösterir.

Çok sunuculu yapıya geçerken depolama mimarisini baştan planlamak gerekir; VDS hizmet paketleri arasında ek depolama ve özel ağ seçenekleri bu kurguyu kolaylaştırır.

Sonuç

Yatay ölçeklemede en sık atlanan taraf dosyalardır: veritabanı ortak olduğu için kayıt her sunucuda görünür, ama dosya yalnızca yüklendiği sunucudadır. En temiz çözüm dosyaları nesne depolamaya taşımaktır — hangi sunucunun isteği aldığı önemsizleşir. Çift yönlü senkronizasyondan kaçının; bir sunucuda silinen dosya diğerinden geri kopyalanabilir ve hiç silinmemiş gibi görünür. Ve geçici dosyaları asla senkronize etmeyin.

Sıkça Sorulan Sorular (SSS)

İkinci sunucuda dosyalar neden görünmüyor?

Çünkü veritabanı ortak ama dosyalar yereldir. Kayıt her sunucuda görünür, o kayda ait dosya ise yalnızca yüklendiği sunucuda vardır. Sonuç, veritabanında var olan ama diske bakıldığında bulunamayan dosyalardır.

En iyi çözüm hangisi?

Dosyaları sunucudan tamamen çıkarıp nesne depolamaya taşımak. Bu, hangi sunucunun isteği aldığını önemsiz hâle getirir ve senkronizasyon ihtiyacını ortadan kaldırır. Ağ dosya sistemi kolaydır ama yeni bir tek arıza noktası yaratır ve çok sayıda küçük dosyada yavaştır.

Çift yönlü senkronizasyon neden riskli?

Aynı dosya iki yerde değişebilir ve hangisinin kazanacağı belirsizdir. Daha sinsi olan davranış ise şudur: bir sunucuda silinen dosya diğerinden geri kopyalanabilir ve hiç silinmemiş gibi görünür — bu, veri silme taleplerinde uyum sorunu üretir.

Diğer sunucuda bozuk dosyalar oluşuyor?

Muhtemelen yükleme sırasındaki yarım dosyalar senkronize ediliyor. Doğru yaklaşım, dosyayı geçici bir adla yazıp tamamlandığında son adına taşımaktır; böylece senkronizasyon yalnızca tamamlanmış dosyaları görür.