Kardiyovasküler cerrahide açık kalp ameliyatı sırasında hasta kalp-akciğer makinesine (ekstrakorporeal dolaşım) bağlanırken en kritik faz geçiş aşamasıdır. Doğal kalbin atımı durdurulurken kan akışı kademeli olarak yapay pompaya aktarılır. Eğer cerrahi ekip doğal kalbi izole etmeden, iki ayrı aortik klempi senkronize etmeden her iki pompayı da aynı anda ve kontrolsüzce devreye sokarsa ne olur? Hastanın beyni eski kalpten dakikada 80 atımla kan alırken, böbrekleri ve bacakları yapay pompadan dakikada 120 atımla farklı basınçta perfüze edilir. İki farklı dolaşım odağı, iki farklı basınç eğrisi ve sonuç: Damar diseksiyonu, çoklu organ yetmezliği ve masada kalan bir hasta. Tıpta buna çift odaklı perfüzyon anomalisi denir.
Bilişim altyapılarında sunucu taşıma (server migration) operasyonları da tam olarak bu hassasiyette bir cerrahi nakildir. Eski sunucudan yeni sunucuya geçerken DNS kayıtlarındaki TTL (Time To Live) süresini önceden düşürmeyi unutan mühendislerin karşılaştığı şey, dağıtık sistemlerin en ölümcül patolojilerinden biri olan Split-Brain (Yarık Beyin) sendromudur.
TTL Nedir ve Neden Dünyanın En İnatçı Önbelleğidir?
DNS (Domain Name System), internetin telefon rehberidir. Ancak milyarlarca cihaz her web sitesi ziyaretinde ana kök (root) sunuculara veya yetkili ad sunucularına (authoritative nameservers) doğrudan soru sormasın diye muazzam bir hiyerarşik önbellekleme mimarisi kurulmuştur.
Bir DNS kaydının yanında yazan sayısal değer (örneğin 86400), o kaydın dünya genelindeki ISP çözümleyicileri (Türk Telekom, Superonline, Cloudflare 1.1.1.1, Google 8.8.8.8) ve son kullanıcı işletim sistemleri tarafından kaç saniye boyunca hafızada tutulacağını belirler.
+-------------------------------------------------------------------------+
| VARSAYILAN DNS KAYDI (86400 Saniye = 24 Saat) |
| |
| example.com. 86400 IN A 195.175.10.50 (Eski Sunucu) |
| |
| 1. Müşteri Türk Telekom DNS'ine sorar: 195.175.10.50 |
| 2. Türk Telekom bu cevabı 24 SAAT boyunca hafızasında dondurur. |
| 3. Siz nameserver'da IP'yi 88.255.20.100 (Yeni Sunucu) yapsanız bile, |
| Türk Telekom 24 saat boyunca eski IP'yi vermeye devam eder! |
+-------------------------------------------------------------------------+
Birçok sistem yöneticisi bu süreyi tamamen göz ardı eder. Cuma gecesi saat 23:00'te toplanılır:
- Eski sunucunun veritabanı yedeği alınır.
- Yeni sunucuya dosyalar ve MySQL veritabanı aktarılır.
- Yeni sunucudaki Nginx/PHP servisleri ayağa kaldırılır.
- cPanel/Cloudflare üzerinden A kaydı yeni sunucunun IP adresine çevrilir.
- Ekip kendi bilgisayarında
ipconfig /flushdnsyapar, sitenin yeni sunucudan açıldığını görür: "Harika, taşıma 15 dakikada bitti, herkese iyi hafta sonları!"
Oysa cehennemin kapıları daha yeni aralanmıştır.
Split-Brain Anatomisi: İki Ayrı Evrende Yaşayan E-Ticaret
Cumartesi sabahı saat 09:00 olduğunda Türkiye genelindeki müşteriler siteye akın etmeye başlar. Ancak internet altyapısı homojen değildir:
- Yeni IP'yi Görenler (%40): Google DNS kullananlar veya yerel ISP'si önbelleği çabuk tazeleyenler yeni sunucuya (
88.255.20.100) bağlanır. Sepete ürün ekler, kredi kartıyla ödeme yapar. Bu siparişler yeni sunucunun veritabanına yazılır (Sipariş ID: 10001, 10002, 10003). - Eski IP'de Kalanlar (%60): Türk Telekom, Vodafone veya yerel kurumsal ağların DNS önbelleği 86400 saniyeyi (24 saat) beklemektedir. Bu kullanıcılar doğrudan eski sunucuya (
195.175.10.50) yönlendirilir. Onlar da siteyi açık görür, ürün satın alır, adres günceller. Bu siparişler eski sunucunun veritabanına yazılır (Sipariş ID: 10001, 10002, 10003 - Auto Increment çakışması!).
┌─────────────────────┐
│ Kullanıcı Havuzu │
└──────────┬──────────┘
│
┌───────────────────┴───────────────────┐
▼ ▼
[Yeni DNS Önbelleği] [Eski DNS Önbelleği]
│ │
▼ ▼
YENİ SUNUCU (IP: .100) ESKİ SUNUCU (IP: .50)
- Sipariş #10001: Ali Bey - Sipariş #10001: Ayşe Hanım
- Stok Düşümü: iPhone (-1) - Stok Düşümü: iPhone (-1)
- Kredi Kartı Çekildi - Kredi Kartı Çekildi
│ │
└───────────────────┬───────────────────┘
▼
[48 Saat Sonra Fark Edilen Kriz]
- Aynı ID ile iki farklı müşteri!
- Olmayan stoklar satıldı!
- İki veritabanı birbirinden koptu!
Pazartesi sabahı şirket merkezinde telefonlar kilitlenir:
- Depo şefi arar: "Ali Bey'in siparişi ile Ayşe Hanım'ın sipariş numarası aynı, kargolar karıştı!"
- Muhasebe arar: "Bankadan 500 bin TL para çekilmiş ama yeni panelde sadece 200 bin TL'lik sipariş görünüyor, 300 bin TL nerede?!"
- Müşteriler arar: "Ben hafta sonu üye oldum, bugün giriş yapamıyorum, 'Böyle bir kullanıcı yok' diyor!"
İki veritabanı zamanda geriye ve ileriye doğru çatallanmış (diverged), veri bütünlüğü tamamen yok olmuştur.
Masadaki Organı Birleştirmek: Veritabanı Birleştirme İşkencesi
İki gün boyunca paralel çalışan iki veritabanını birleştirmek, kıymadan tekrar biftek yapmaya çalışmak kadar zahmetli ve hataya açıktır.
- Auto-Increment Çakışmaları: Her iki veritabanı da aynı ID'leri farklı kullanıcılara, siparişlere ve faturalara dağıtmıştır.
- Foreign Key Felaketi: Sipariş kalemleri (
order_items), adresler ve kargo kayıtları birbirine girmiştir. - Mühendisler günlerce SQL betikleri yazarak eski sunucudaki ID'leri
+100000öteleyip yeni veritabanına aktarmak için gecelerce uyumaz. Birçok şirket bu süreçte binlerce liralık mükerrer kargo ve yanlış faturalandırma zararına uğrar.
Profesyonel Taşıma Protokolü: Adım Adım Cerrahi Plan
Bu felaketi önlemenin yolu bir komut satırı sihirbazlığı değil, askeri bir disiplinle takvime sadık kalmaktır.
Faz 1: T - 72 Saat (Hazırlık ve TTL Düşürme)
Taşıma işleminden en az 3 gün önce DNS yetkili sunucusuna girilir ve taşınacak domainin TTL süresi en düşük güvenli seviyeye çekilir.
# Eski DNS Kaydı:
example.com. 86400 IN A 195.175.10.50
# Yapılan Değişiklik (TTL = 300 Saniye / 5 Dakika):
example.com. 300 IN A 195.175.10.50Bu değişiklik yapıldıktan sonra 72 saat beklenmelidir! Neden? Çünkü dünyadaki tüm DNS çözümleyicilerinin hafızasındaki eski 24 saatlik önbelleğin süresi dolmalı ve yeni 5 dakikalık TTL kuralı küresel olarak kabul edilmelidir.
Faz 2: T - 0 (Taşıma Anı ve Eski Sunucuyu Klemplemek)
Taşıma gecesi geldiğinde yapılacak ilk iş, eski sunucunun veritabanına yazmayı durdurmaktır. Tıpkı kalbi baypas etmeden önce aort damarını klemplemek gibi:
-
Eski Sunucuda Bakım Modu / Read-Only:
Eski sunucudaki web sunucusunda tüm dinamik POST istekleri engellenmeli veya veritabanıREAD ONLYmoduna alınmalıdır:FLUSH TABLES WITH READ LOCK; SET GLOBAL read_only = ON; -
Nginx Seviyesinde Geçici Reverse Proxy:
Eski sunucuyu tamamen kapatmak yerine, eski sunucuya gelen istekleri arka planda yeni sunucuya tünelleyen bir Nginx ters proxy kurulabilir:# Eski sunucu Nginx yapılandırması: server { listen 80; listen 443 ssl; server_name example.com; location / { proxy_pass https://88.255.20.100; # Yeni Sunucu IP'si proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }Bu sayede eski DNS kaydında kalan kullanıcılar bile fiziksel olarak eski sunucuya gitseler dahi, istekleri arka planda yeni sunucudan yanıtlanır. Split-brain ihtimali sıfıra iner!
-
DNS A Kaydını Değiştirme:
A kaydı yeni IP'ye yönlendirilir. TTL süresi 300 saniye olduğu için tüm dünya maksimum 5 dakika içinde yeni sunucuya akacaktır.
Faz 3: T + 48 Saat (Normalleşme)
Geçiş başarıyla tamamlandıktan ve sistemin kararlılığı doğrulandıktan sonra TTL süresi tekrar 86400 saniyeye (veya 43200 / 12 saat) yükseltilerek DNS sunucularının üzerindeki anlık sorgu yükü azaltılır.
Sonuç
DNS'te TTL süresi, sisteme verilen bir zaman aşımı emridir. Zamanı bükemezsiniz; internet altyapısının hafızasını zorla silemezsiniz.
Planlanmamış, TTL süresi düşürülmeden ve eski sunucu klemplenmeden yapılan her sunucu taşıması; verilerinizin ikiye bölünmesine, müşterilerinizin birbirinin siparişine girmesine ve 48 saatlik kabus dolu bir acil servis krizine davetiyedir. Altyapı taşırken acele etmeyin; önce damarları hazırlayın, sonra nakli gerçekleştirin.