Sunucu IP Değişince Kesintisiz Taşıma: DNS, TTL ve Plan

Sunucu IP’si değiştiğinde asıl risk, kullanıcıların uygulamaya aynı anda iki farklı adresten ulaşması veya eski IP’ye yönlenmeye devam etmesidir. Bu yazıda, IP değişimi sırasında web uygulamanızın kesinti almadan taşınması için DNS zamanlaması, TTL yönetimi, hazır yönlendirme (warm) ve ölçülebilir bir rollback planı kuracağız. Hedef; taşınmayı bir kerelik “düzeltme” değil, tekrar edilebilir bir operasyon haline getirmek.

IP değişiminde kesinti nereden çıkar?

IP değişimi sırasında kesinti genellikle şu üç sebepten doğar:

DNS yayılımı (propagation) bitmeden kullanıcılar hâlâ eski IP’yi çözümler.
Yeni sunucu IP’ye geçtiğinde uygulama tam hazır değil (dosyalar, ortam değişkenleri, veritabanı bağlantısı, sertifika).
Taşıma sonrası hatayı fark ettiğinizde hızlı bir geri dönüş (rollback) planınız yoktur; DNS geri alınana kadar kesinti uzar.

Bu üç noktayı kontrol altına almak için aşağıdaki sıra izlenmelidir: DNS TTL’i düşür → yeni ortamı hazırla ve test et → ağı kademeli kesmeden yönlendir → izleme ile ölç → rollback’i önceden tasarla.

1) DNS TTL stratejisi: Ne kadar erken, ne kadar düşürülmeli?

DNS TTL (Time To Live), istemcilerin “bu kaydı ne kadar süre önbelleğe alacağını” belirler. TTL kısa olursa güncelleme daha hızlı yayılır; TTL uzun olursa eski IP’ye bağlı kalan kullanıcı sayısı artar.

Pratik TTL takvimi (örnek)

Aşağıdaki plan, çoğu senaryoda güvenli çalışır. Uygulamanızın kritikliği daha yüksekse daha konservatif gidin.

Planlamadan 48 saat önce: TTL’i 300–600 sn bandına çekin.
Planlamadan 12 saat önce: TTL’i 60–120 sn bandına indirin.
Kesinti olmayan taşıma anında: TTL zaten düşüktür; kayıt güncellemeleri hızlı yayılır.

Not: Bazı resolver’lar TTL’i tam uygulamayabilir; bu yüzden “TTL 60 olunca 60 saniyede biter” varsayımını tek başına doğruluk kabul etmeyin. Yayılımın gerçek zamanını ölçmek gerekir (aşağıda var).

Hangi DNS kayıtlarını değiştireceksiniz?

Taşıma yapılacak giriş noktanıza göre genelde şu kayıtlar etkilenir:

A / AAAA: Uygulama doğrudan IP’ye bağlanıyorsa.
CNAME: Bir yük dengeleyiciye (LB) veya başka bir isme bağlanıyorsa.
ALIAS/ANAME: Bazı sağlayıcılarda platforma özgü davranışlar olabilir.

Kesintiyi azaltmak için hedef, DNS değişimini “tek adımda” değil, hazır ortam üzerinden tek yönlü trafik geçişi şeklinde yönetmektir.

2) Hazır yönlendirme (warm) kurulumu: Yeni IP’de uygulama hazır olsun

DNS değiştirmeden önce yeni IP’nin “gelen trafiği karşılayacak” halde olması gerekir. Buradaki kritik ölçüt, uygulamanın yalnızca ayağa kalkmış olması değil; gerçek akışların çalıştığının kanıtıdır.

Kontrol listesi: Yeni sunucuda doğrulama

Taşımadan önce yeni sunucuda şu kontroller yapılır:

Uygulama servisleri ayağa kalktı mı? (ör. Nginx/Apache + uygulama runtime)
Versiyon uyumu: Kod aynı mı, config aynı mı, env değişkenleri aynı mı?
Veritabanı bağlantısı: Yeni sunucu DB’ye bağlanıyor mu? Yetkiler tamam mı?
Dosya ve statik içerik: uploads, assets, media gibi dizinler var mı?
TLS/sertifika: Aynı domain için sertifika doğru mu? (ACME/Let’s Encrypt kullanıyorsanız geçişte doğrulama yöntemleri değişebilir.)
Health check endpoint: Uygulama durumunu dışarıdan doğrulayabileceğiniz bir endpoint tanımlı mı? (ör. /healthz)

Warm yönlendirme uygulama modeli

En pratik model şudur:

Yeni sunucuda uygulamayı kurup ayağa kaldırın.
DNS değişmeden önce uygulama URL’sini IP üzerinden test edin (ör. http://new-ip/healthz).
Sonra servis, DNS geçişinde anlık olarak trafik alacak şekilde hazır bekletilir.

DNS değişince “hazır olmayan” yeni taraftan hata gelirse rollback kaçınılmaz olur. O yüzden warm aşaması kasten yapılır.

3) Yönlendirme adımı: DNS geçişini kademeli ve ölçülebilir yapın

DNS geçişinde “tek büyük hamle” yerine izleme ile doğrulanan bir yaklaşım önerilir.

Adım adım DNS geçiş akışı

TTL düşürüldü mü? Kontrol edin.
Yeni sunucuda health check başarılı mı?
DNS kaydını hedef IP’ye güncelleyin.
Yayılımı anlık ölçün.
Hata oranı veya gecikme artışı görülmezse beklenen trafiğe geçişin tamamlandığını doğrulayın.

Gerçek yayılım ölçümü nasıl yapılır?

Basit ama etkili yöntem: Çeşitli ağlardan (mobil, farklı ISP, farklı ülke/VM) dig/nslookup ile DNS yanıtlarını kontrol edin.

Örnek komutlar: - dig +short your-domain.com - nslookup your-domain.com

Ek olarak uygulama tarafında: - Ortalama yanıt süresi (latency) - HTTP durum kodları (özellikle 502/503/504) - Uygulama loglarında hata spike’ı

Bu ölçümler, “DNS güncellendi ama kullanıcılar hâlâ eski IP’ye gidiyor mu?” sorusunu pratikte yanıtlar.

4) Önceden rollback (geri dönüş) planı oluşturun

Rollback planı yoksa rollback “panik hamlesi” olur. Plan varsa rollback dakikalar içinde gerçekleşir.

Rollback ne zaman yapılmalı?

Aşağıdaki eşikler tutarlı bir rollback trigger’ı olabilir:

Yeni IP’ye geçen trafiğin 5 dakikada hata oranı belirgin artıyorsa (ör. 5xx toplamı %1’den %5’e çıkıyor gibi)
Health check 1–2 dakikadan uzun süre başarısız ise
Kritik endpoint’lerde (login, checkout, API) hata spike’ı varsa

Net hedef: “Sorun var mı?” kararını log ve ölçümle verin; hisle değil.

Rollback nasıl yapılır?

Rollback genelde aynı iki yolla yapılır:

DNS’yi eski IP’ye geri al: TTL zaten düşürüldüğü için geri dönüş hızlı olur.
Yeni IP tarafında servis kapatma: Nginx/uygulama stop veya geçici 503 döndürme.

DNS geri alındığında bile bazı resolver’lar eski kaydı önbelleklediği için, hatalı davranışı durdurmak adına yeni sunucuda “servis kapat + hızlı 503” yaklaşımı kullanılabilir.

İki aşamalı plan örneği

Aşama A (hızlı düzeltme): Yeni tarafta bir sorun tespit edilirse uygulamayı geçici olarak 503 moduna al.
Aşama B (DNS geri dönüş): Ölçümler düzene girmiyorsa DNS’yi eski IP’ye geri çevir.

Bu sıra, kullanıcıların “tamamen kopmak” yerine “makul hata” görmesini sağlar.

5) Hazır yönlendirme ve rollback’i destekleyen operasyonel önlemler

Kesintisiz taşımayı kolaylaştıran birkaç somut önlem var.

Yedekleme (backup) değil, rollback’e uygun “kopya” yaklaşımı

Snapshot yedekleme tek başına güvence değildir; rollback için hedef, yeni ortama ait hataları anında geri sarabilmektir. Bu yüzden: - Uygulama kodunu ve config’i aynı sürümle yeniden kurabilecek şekilde sürümleme yapın. - DB tarafında kritik değişikliklerde “geri alınabilir” bir akış kullanın (ör. migration planı).

Sertifika (TLS) geçişi

Sertifika yönetimi kesinti yaratabilir. Uygulama yeni IP’de TLS handshake başarısız olursa kullanıcılar hatayı görür. - Yeni sunucuda sertifika dosyaları hazır olmalı. - Otomatik sertifika yenileme (ACME) gerekiyorsa yeni IP’nin doğrulama mekanizmasına (HTTP-01/DNS-01) uygun kurulum yapın.

CDN varsa TTL stratejisi iki katmanlı düşünülür

CDN cache’leri DNS zamanlamasını dolaylı etkiler. Eğer CDN kullanıyorsanız: - DNS TTL düşürmek yine önemlidir, ancak CDN cache temizliği gerekiyebilir. - Origin (yeni sunucu) erişimi CDN’den doğrulanmalıdır.

6) En sık yapılan hatalar ve net çözümleri

Aşağıdaki hatalar, “DNS değiştirdim ama düzelmiyor” şikayetlerinin başlıca sebepleridir.

Yeni sunucuda env/config eksikliği - Çözüm: Yeni sunucuda env değerlerini ve config template’lerini birebir eşleyin.
Veritabanı bağlantısının çalışmaması - Çözüm: IP/port/username/grant kontrolü yapın; DB bağlantı testini taşımadan önce doğrulayın.
Sertifika veya yönlendirme (redirect) uyumsuzluğu - Çözüm: Nginx/Apache server block ayarlarını ve 301/302 kurallarını kontrol edin.
TTL’i düşürmeden geçiş yapmak - Çözüm: Zorunlu değilse 48 saat/12 saat planını uygulayın.
Rollback kriteri belirlememek - Çözüm: 5xx hata oranı, health check durumu, latency eşiği belirleyin.

7) Uygulama taşımayı kolaylaştıran hedef mimari: Tek giriş noktasına geçin

En sağlam çözüm, IP değişiminde DNS değişimini azaltacak bir “ortak giriş” yapısı kurmaktır.

Yük dengeleyici (LB) veya ters proxy ile azaltma

Eğer servisiniz bir load balancer arkasında ise, IP değişimi LB tarafında daha yönetilebilir hale gelir.
Uygulama seviyesinde değişen tek şey upstream hedefler olabilir.

Bu yaklaşım her zaman mümkün değildir ama özellikle VDS/VPS/dedicated karışık mimarilerde IP kaynaklı olayların etkisini ciddi düşürür.

Sonuç: Aksiyon planı ile kesintiyi minimize edin

Sunucu IP’si değiştiğinde kesintiyi büyüten şey DNS belirsizliği ve yeni ortamın hazır olmamasıdır. Bu nedenle aksiyon sırası net olsun: TTL’i kademeli düşürün, yeni sunucuda warm doğrulama yapın, DNS geçişini ölçümle takip edin ve rollback trigger’ını önceden belirleyin. İsterseniz NetKıyas’ta takip ettiğiniz altyapı ihtiyaçlarına göre (VDS/VPS/dedicated) geçiş için uygun performans ve yönetim seviyesini de yeniden değerlendirin; amaç tek seferlik panik değil, tekrarlanabilir ve ölçülebilir bir taşıma süreci kurmaktır.