Eşleme Gecikmesi: Yedek Sunucunuz Ne Kadar Geride?
İkinci bir sunucunuz var ve veriler oraya sürekli kopyalanıyor. Arıza anında devreye alacaksınız. Ama devreye aldığınızda son yarım saatin verisi orada olmayabilir — çünkü eşleme anlık değildir ve gecikme çoğu zaman ölçülmez.
Bu yazı, kopya sunucudaki gecikmeyi ele alıyor.
İki Eşleme Modeli
| Eşzamanlı | Eşzamansız |
|---|---|
| Kopya onaylamadan işlem bitmez | İşlem hemen biter |
| Veri kaybı yok | Gecikme kadar kayıp olabilir |
| Yazma yavaşlar | Yazma hızlı kalır |
Üçüncü satır tercihi belirler: eşzamanlı eşlemede her yazma işlemi ikinci sunucunun onayını bekler — bu, ağ gecikmesini doğrudan uygulama yanıt süresine ekler ve uzak lokasyonlarda kabul edilemez hâle gelir.
Aynı veri merkezinde eşzamanlı eşleme uygulanabilir.
Şehirler arasında ise genellikle uygulanamaz.
Bu nedenle çoğu yapı eşzamansız çalışır.
Gecikmeyi Ölçmek
- Saniye cinsinden gecikme.
- İşlenmemiş kayıt miktarı.
- Son uygulanan işlem zamanı.
İkinci madde daha güvenilir bir göstergedir: saniye cinsinden gecikme, trafik olmadığı anlarda sıfır görünebilir ve yanıltıcıdır — birikmiş işlem miktarına bakmak gerçek durumu daha doğru yansıtır.
Sessiz saatlerde gecikme ölçümü anlamsızlaşır.
Üçüncü madde ise kesin bir zaman noktası verir.
Bu üç ölçüt birlikte değerlendirilmelidir.
Gecikme Nedenleri
- Ağ bant genişliği yetersizliği.
- Kopya sunucunun yavaş olması.
- Tek iş parçacıklı uygulama.
- Uzun süren tekil işlemler.
Üçüncü madde en sık karşılaşılan sınırdır: ana sunucu değişiklikleri paralel üretirken kopya sunucu onları tek tek uyguluyorsa, yazma yoğun dönemlerde gecikme kaçınılmaz olarak birikir — kopyanın donanımı güçlü olsa bile.
Modern sürümler paralel uygulamayı destekler.
Bu özellik açıkça etkinleştirilmelidir.
Dördüncü madde ise toplu güncellemelerde yaşanır.
Toplu İşlem Etkisi
| İşlem | Kopyadaki etki |
|---|---|
| Milyon satırlık güncelleme | Gecikme fırlar |
| Büyük tablo silme | Gecikme fırlar |
| Parça parça işlem | Gecikme kontrollü kalır |
Üçüncü satır çözümü verir: büyük veri işlemlerini küçük parçalara bölmek yalnızca ana sunucuyu değil kopya sunucuyu da korur — tek büyük işlem kopyada saatlerce gecikme üretebilir.
Bu gecikme sırasında kopya kullanılamaz.
Okuma yükü ona yönlendirilmişse eski veri döner.
Parçalar arasında bekleme eklemek gecikmeyi eritir.
Okuma İçin Kullanmak
- Raporlar kopyadan okunabilir.
- Ama veri güncel olmayabilir.
- Kritik okumalar ana sunucudan yapılmalı.
Üçüncü madde ince ama önemli bir kuraldır: bir kaydı yazdıktan hemen sonra kopyadan okumak, henüz eşlenmemiş olduğu için eski değeri döndürebilir — kullanıcı kendi yaptığı değişikliği göremez.
Bu, açıklaması zor bir hata olarak görünür.
Yazma sonrası okumalar ana sunucuya yönlendirilmelidir.
Raporlar ve arama gibi işler kopyadan yapılabilir.
Devir Kararı
- Gecikme miktarı bilinmeli.
- Kabul edilebilir kayıp tanımlı olmalı.
- Karar önceden verilmiş olmalı.
Üçüncü madde kriz anında zaman kazandırır: arıza anında "kaç dakikalık veri kaybını göze alıyoruz" sorusunu tartışmak dakikalar kaybettirir — bu eşik önceden belirlenip yazılı olmalıdır.
Karar teknik değil iş kararıdır.
Yönetimle birlikte belirlenmelidir.
Eşik aşıldıysa devir yerine onarım tercih edilebilir.
Geri Dönüş
| Adım | Dikkat |
|---|---|
| Kopya ana hâline gelir | Yön değişir |
| Eski ana geri gelir | Artık geridedir |
| Yeniden eşleme kurulur | Yön ters çevrilir |
İkinci satır tehlikeli bir andır: devirden sonra geri gelen eski ana sunucuyu düşünmeden devreye almak, iki sunucunun da yazma kabul etmesine ve verilerin ayrışmasına yol açar — bu durumdan çıkmak çok zordur.
Eski ana sunucu önce kopya rolüne alınmalıdır.
Yön açıkça değiştirilmelidir.
Bu adım tatbikatta mutlaka denenmelidir.
Uyarı Kurmak
- Gecikme eşiği belirlenir.
- Aşımda uyarı verilir.
- Eşleme durması ayrı uyarı olmalı.
Üçüncü madde en kritik uyarıdır: eşlemenin tamamen durması gecikme grafiğinde bir noktadan sonra sabit görünebilir — durma ile yavaşlama farklı olaylardır ve ayrı ayrı izlenmelidir.
Duran bir eşleme, yedeğinizin olmaması demektir.
Bu durum günlerce fark edilmeyebilir.
Eşleme durumu ayrıca kontrol edilmelidir.
Tatbikat
- Planlı devir denemesi yapın.
- Süreyi ölçün.
- Geri dönüşü de deneyin.
Üçüncü madde çoğu tatbikatta atlanır: devir tatbikatı yapan ekiplerin çoğu geri dönüşü hiç denemez — oysa gerçek bir olayda asıl karmaşık adım, sistemi eski düzenine döndürmektir.
Geri dönüş genellikle devirden daha zordur.
Adımlar yazılı hâle getirilmelidir.
Yılda en az bir kez tekrarlanmalıdır.
İki sunuculu bir eşleme yapısı kurmak için uyumlu donanım ve ağ gerekir; dedicated server çözümleri ile yedekli mimarinizi birlikte planlayabilirsiniz.
Sonuç
Kopya sunucu varlığı yeterli değildir; ne kadar geride olduğu bilinmelidir. Eşzamansız eşlemede gecikme kadar veri kaybı yaşanabilir. Gecikmeyi saniye değil birikmiş işlem miktarıyla ölçün, büyük işlemleri parçalayın ve eşlemenin durmasını yavaşlamadan ayrı bir uyarı olarak izleyin. Devir kadar geri dönüşü de tatbik edin.
Sıkça Sorulan Sorular (SSS)
Devir yaparsam veri kaybeder miyim?
Eşzamansız eşlemede evet, gecikme kadar. Eşzamanlı eşlemede kayıp olmaz ama her yazma ikinci sunucunun onayını beklediği için ağ gecikmesi doğrudan yanıt süresine eklenir; uzak lokasyonlarda bu kabul edilemez hâle gelir.
Gecikmeyi nasıl doğru ölçerim?
Saniye cinsinden gecikme trafik olmadığı anlarda sıfır görünebilir ve yanıltıcıdır. Birikmiş işlem miktarına ve son uygulanan işlem zamanına da bakın; üç ölçüt birlikte değerlendirilmelidir.
Raporları kopyadan okuyabilir miyim?
Okuyabilirsiniz ama veri güncel olmayabilir. Bir kaydı yazdıktan hemen sonra kopyadan okumak eski değeri döndürebilir ve kullanıcı kendi değişikliğini göremez. Yazma sonrası okumaları ana sunucuya yönlendirin.
Eski ana sunucu geri gelince ne yapmalıyım?
Düşünmeden devreye almayın. İki sunucunun da yazma kabul etmesi verilerin ayrışmasına yol açar ve bu durumdan çıkmak çok zordur. Eski ana sunucuyu önce kopya rolüne alın ve eşleme yönünü açıkça değiştirin.
