Kesinti Anında DNS Devri: Trafiği Yedek Adrese Almak
Sunucunuz çöktü ve yedek bir sunucunuz hazır bekliyor. DNS kaydını değiştiriyorsunuz ama ziyaretçilerin çoğu hâlâ çalışmayan adrese gidiyor. Değişiklik yapıldı, panel doğru gösteriyor, yine de trafik akmıyor. Sorun, hazırlığın kesinti anında yapılmasında.
Bu yazı, DNS ile yedek adrese geçişi ele alıyor.
DNS'in Devir Sınırı
- Kayıt değiştirilir.
- Çözümleyiciler eski değeri saklar.
- Süre dolana kadar eski adrese gidilir.
Üçüncü adım geçişin hızını tamamen belirler: DNS ile devir, kaydın önbellek süresinden daha hızlı olamaz — süre bir saat olarak ayarlıysa, değişikliği anında yapsanız bile bazı ziyaretçiler bir saat boyunca çalışmayan sunucuya gitmeye devam eder.
Bu, DNS'in doğasından gelen bir sınırdır.
Panelde değişiklik anında görünür ama dünyada görünmez.
Bu nedenle hazırlık önceden yapılmalıdır.
Önceden Süre Düşürmek
| Süre | Devir hızı |
|---|---|
| Bir gün | Kabul edilemez |
| Bir saat | Yavaş |
| Beş dakika | İyi |
| Bir dakika | Çok hızlı, sorgu yükü artar |
Üçüncü satır çoğu senaryo için doğru dengedir: devir yeteneği isteyen kayıtlarda süreyi beş dakika civarında tutmak, makul bir sorgu yüküyle hızlı geçiş sağlar — ve bu ayar kesinti olmadan çok önce yapılmalıdır.
Kesinti anında süreyi düşürmek işe yaramaz.
Çünkü eski uzun süre zaten önbelleğe alınmıştır.
Dördüncü satır ise yalnızca kritik sistemlerde tercih edilir.
Otomatik Devir
- Sağlık kontrolü yapılır.
- Arıza tespit edilir.
- Kayıt otomatik değiştirilir.
Üçüncü madde insan gecikmesini ortadan kaldırır: gece yarısı yaşanan bir arızada kaydı elle değiştirecek birinin uyanması ve müdahale etmesi dakikalar hatta saatler alır — otomatik devir bu süreyi saniyelere indirir.
Sağlık kontrolü birden fazla noktadan yapılmalıdır.
Tek noktadan yapılan kontrol yanlış alarm üretir.
Ağ sorunu, sunucu arızası gibi görünebilir.
Yanlış Devir Riski
- Geçici bir sorun arıza sanılır.
- Trafik yedeğe alınır.
- Gereksiz bir geçiş yaşanır.
Üçüncü madde beklenmedik sorunlar üretebilir: yedek sunucu ana sunucunun tam eşi değilse, gereksiz bir devir asıl arızadan daha büyük soruna yol açabilir — eski veriye sahip bir yedeğe geçmek, veri tutarsızlığı üretir.
Bu nedenle devir eşiği dikkatli belirlenmelidir.
Birkaç ardışık başarısız kontrol beklenmelidir.
Geri dönüş de otomatik olmamalıdır.
Veri Tarafı
| Yedek türü | Devir sonrası durum |
|---|---|
| Anlık eşlenen yedek | Veri kaybı yok |
| Periyodik kopyalanan yedek | Son değişiklikler kayıp |
| Yalnızca statik sayfa | İşlem yapılamaz |
Üçüncü satır sınırlı ama değerli bir seçenektir: tam bir yedek altyapı kurulamıyorsa bile, kesinti anında bilgilendirme yapan basit bir statik sayfaya devretmek, ziyaretçinin hata ekranıyla karşılaşmasından çok daha iyidir.
Bu, marka algısını korur.
İkinci satır ise veri kaybı penceresini tanımlar.
Bu pencere önceden bilinmeli ve kabul edilmelidir.
E-posta Kayıtları
- Posta kayıtları ayrı ele alınmalı.
- İkincil sunucu tanımlanabilir.
- Gönderenler otomatik dener.
Üçüncü madde e-postayı web trafiğinden daha dayanıklı kılar: gönderen sistemler ilk posta sunucusuna ulaşamadığında ikincil sunucuyu kendiliğinden dener ve bu, DNS önbelleğinden bağımsız çalışır — web tarafında böyle bir mekanizma yoktur.
Bu nedenle e-posta için devir gerekmez.
İkincil kayıt tanımlamak yeterlidir.
İkincil sunucu iletileri kuyrukta tutup sonra teslim eder.
Devri Test Etmek
- Planlı bir tatbikat yapın.
- Geçiş süresini ölçün.
- Yedeğin çalıştığını doğrulayın.
Üçüncü madde en sık atlanan adımdır: hiç test edilmemiş bir yedek sunucu, gerçek kesinti anında çalışmayabilir — eksik yapılandırma, güncel olmayan sertifika veya erişilemeyen veritabanı ancak tatbikatta ortaya çıkar.
Tatbikat, düşük trafikli bir saatte yapılmalıdır.
Bulunan eksikler kayıt altına alınmalıdır.
Yılda en az bir kez tekrarlanmalıdır.
DNS Dışı Yöntemler
- Yük dengeleyici daha hızlıdır.
- İçerik ağı devri destekleyebilir.
- DNS son çare olmalıdır.
Birinci madde önemli bir gerçeği söyler: önünde bir yük dengeleyici bulunan bir yapıda devir saniyeler içinde ve önbellekten bağımsız gerçekleşir — DNS tabanlı devir, bu imkânın olmadığı durumların çözümüdür.
Aynı adres korunduğu için önbellek sorunu yaşanmaz.
Üçüncü madde ise doğru beklentiyi kurar.
DNS devri her zaman kısmi ve gecikmelidir.
Alan adı kayıtlarınızın devir hazırlığını alan adı kayıt ve yönetim hizmeti ile önceden planlayabilirsiniz.
Sonuç
DNS ile devrin en önemli kuralı hazırlığın zamanıdır: devir, kaydın önbellek süresinden daha hızlı olamaz ve kesinti anında süreyi düşürmek işe yaramaz. Süreyi önceden beş dakika civarına indirin, sağlık kontrolünü birden fazla noktadan yapın ve yedeği mutlaka test edin — hiç test edilmemiş bir yedek sunucu gerçek kesintide çalışmayabilir. Mümkünse yük dengeleyici tercih edin.
Sıkça Sorulan Sorular (SSS)
Kaydı değiştirdim ama trafik hâlâ eski sunucuya gidiyor?
Çözümleyiciler eski değeri önbellekte tutuyor. Devir, kaydın önbellek süresinden daha hızlı olamaz; süre bir saatse bazı ziyaretçiler bir saat boyunca çalışmayan sunucuya gitmeye devam eder. Panelde değişiklik anında görünür ama dünyada görünmez.
Süreyi kesinti anında düşürebilir miyim?
Düşürebilirsiniz ama işe yaramaz; eski uzun süre zaten önbelleğe alınmıştır. Bu ayar kesinti olmadan çok önce yapılmalıdır. Devir yeteneği isteyen kayıtlarda beş dakika civarı makul bir dengedir.
Otomatik devir riskli mi?
Yanlış devir riski vardır. Sağlık kontrolü tek noktadan yapılırsa ağ sorunu sunucu arızası gibi görünür ve gereksiz geçiş yaşanır. Yedek sunucu ana sunucunun tam eşi değilse bu, asıl arızadan büyük soruna yol açabilir. Birkaç ardışık başarısız kontrol bekleyin.
E-posta için de devir kurmalı mıyım?
Gerekmez. Gönderen sistemler ilk posta sunucusuna ulaşamadığında ikincil sunucuyu kendiliğinden dener ve bu, DNS önbelleğinden bağımsız çalışır. İkincil bir posta kaydı tanımlamak yeterlidir; ikincil sunucu iletileri kuyrukta tutup sonra teslim eder.
