Failover ve Fallback Farkı

Failover ve fallback, aynı olayın iki ayrı yarısını tarif eden ama sürekli birbirinin yerine kullanılan iki terim. Failover, birincil sistem arızalandığında trafiğin yedeğe geçmesidir; fallback ise sorun giderildikten sonra normale dönüş sürecidir. Bu ayrımı önemsiz bir kelime oyunu sanıp geçmek, üretimde gerçekten pahalıya patlayan bir hataya dönüşebilir — çünkü ikisi tamamen farklı risk profillerine sahiptir ve birini otomatikleştirirken diğerini otomatikleştirmemek gerekir.

Bu yazıda önce iki kavramı net biçimde ayıracağız, arada sıkışan üçüncü terim olan "failback"i yerine oturtacağız ve "fallback" kelimesinin yazılım dünyasındaki ikinci anlamına da değineceğiz. Ardından asıl meseleye geleceğiz: neden failover otomatik olmalı ama geri dönüş neredeyse hiçbir zaman otomatik olmamalı. Sonunda pratik bir geri dönüş kontrol listesi, uygulama katmanında zarif bozulma örnekleri ve bu konuda en sık düşülen tuzaklar var.

Failover: Arıza Anında Devretme#

Failover, birincil bileşen kullanılamaz hale geldiğinde hizmetin yedek bileşen üzerinden sürmesini sağlayan geçiştir. Anahtar kelime "arıza anında"dır: failover, planlamadığın bir olaya verilen otomatik cevaptır ve hızlı olması gerekir, çünkü geçiş tamamlanana kadar hizmet kesintidedir.

İyi bir failover mekanizmasının üç özelliği vardır. Hızlıdır — tespit ve geçiş toplam birkaç saniye sürmelidir. Otomatiktir — gece 03:00'te kimseyi beklememelidir. Muhafazakârdır — geçici bir dalgalanmayı arıza sanıp gereksiz yere devretmemelidir. Bu üçü arasındaki denge, sağlık kontrolü eşikleriyle kurulur.

Farklı katmanlarda failover farklı biçimlerde görünür:

Failover'ın en kritik yanı, geçişten sonra sistemin bozulmuş bir durumda çalışıyor olmasıdır. Yedeğe geçtiysen artık yedeğin yoktur; ikinci bir arıza seni tamamen durdurur. Bu yüzden failover bir çözüm değil, sorunu gidermek için kazanılmış bir süredir. Bunu unutup "sistem çalışıyor, sonra bakarız" demek, tek yedekli bir kurulumda oynanmış tehlikeli bir kumardır.

Failover mekanizmalarının nasıl kurulduğunu ayrıntılı görmek istersen Keepalived ve VRRP ile failover yazısı sanal IP tarafını, yük dengeleyici nedir yazısı ise uygulama katmanını ele alıyor.

Fallback: Kontrollü Geri Dönüş#

Fallback, arıza giderildikten sonra sistemin normal çalışma düzenine dönmesidir. Failover'ın tersi yönde bir hareket gibi görünse de karakteri tamamen farklıdır: failover acil ve zorunludur, fallback ise isteğe bağlı ve planlıdır. Yedek sistem üzerinde çalışmaya devam edebiliyorsan, geri dönmek için acele etmen gerekmez.

Bu noktada terim netleştirmesi yapalım. Literatürde arıza sonrası birincile dönüşün daha kesin adı failback'tir. "Fallback" kelimesi ise iki anlamda kullanılır: birincisi failback ile aynı anlamda (normale dönüş), ikincisi ise "birincil yol kullanılamadığında devreye giren alternatif yol" anlamındadır. İkinci kullanım yazılım tarafında çok yaygındır — yazı tipi fallback'i, DNS fallback'i, önbellek fallback'i gibi.

Bu tablodaki üçüncü satır kafa karışıklığının kaynağıdır: uygulama içi fallback otomatik olmalıdır, altyapı seviyesindeki failback ise olmamalıdır. İkisi aynı kelimeyle anıldığı için "fallback otomatik olsun mu" sorusunun tek bir cevabı yoktur; hangisinden bahsettiğini netleştirmeden konuşmak yanlış kararlar üretir.

Otomatik Geri Dönüş Neden Tehlikelidir#

Failback'i otomatikleştirmek ilk bakışta mantıklı görünür: birincil düzeldi, hemen geri dönelim. Ama üretimde bunun üç ciddi sorunu vardır.

Birincisi, ikinci bir kesinti üretir. Failover sırasında bir kesinti yaşadın; otomatik geri dönüş, aynı gün içinde ikinci bir kesinti daha ekler. Üstelik bu ikincisi tamamen gereksizdir — sistem yedek üzerinde sorunsuz çalışıyordu.

İkincisi, gidip gelme (flapping) riski yaratır. Arızanın sebebi hâlâ oradaysa ve birincil aralıklı olarak düzelip bozuluyorsa, otomatik geri dönüş sistemi iki düğüm arasında sürekli gidip gelen bir duruma sokar. Her geçiş bağlantıları koparır; kullanıcı deneyimi tek bir uzun kesintiden çok daha kötü olur.

Üçüncüsü ve en tehlikelisi, veri kaybına yol açabilir. Failover'dan sonra yazma işlemleri yedek düğüm üzerinde birikmiştir. Birincil geri geldiğinde onda o veriler yoktur. Otomatik olarak birincile dönersen, yedekte biriken tüm yazmalar bir anda görünmez olur. Veritabanlarında bu senaryo felakete dönüşür: sistem eski bir duruma geri sarar, kullanıcılar kaybolan siparişler bildirir ve iki düğümün verisini birleştirmek çoğu zaman elle ve hatalı biçimde yapılır.

Bu yüzden failover mekanizmalarında geri dönüşü kapatmak standart bir uygulamadır. Keepalived tarafında bu nopreempt ile yapılır:

vrrp_instance VI_1 {
    # nopreempt kullanmak için her iki düğümde de BACKUP yazmalısın
    state BACKUP
    interface eth0
    virtual_router_id 51
    priority 110
    advert_int 1
    nopreempt          # eski MASTER dönünce VIP'yi geri ALMASIN

    virtual_ipaddress {
        10.0.0.10/24 dev eth0
    }
}

Veritabanı tarafında ise kural daha da katıdır: failover'dan sonra eski birincili asla olduğu gibi geri açma. Doğru yordam, onu yeni birincilin yedeği olarak yeniden kurmaktır.

# PostgreSQL: eski birincili yeni birincilin yedeği haline getir
sudo systemctl stop postgresql

# Zaman çizgisini yeni birincile göre hizala
sudo -u postgres pg_rewind \
  --target-pgdata=/var/lib/postgresql/16/main \
  --source-server="host=10.0.0.32 user=replikator dbname=postgres"

# Sonra standby olarak başlat ve çoğaltmanın yakaladığını doğrula
sudo systemctl start postgresql
sudo -u postgres psql -c "SELECT pg_is_in_recovery();"   -- t dönmeli

Eski birincili "nasılsa aynı veriler var" diyerek doğrudan açmak, iki düğümün de kendini birincil sandığı split-brain durumunu yaratır ve bu, veri katmanında başına gelebilecek en kötü şeydir.

Geri Dönüş Öncesi Kontrol Listesi#

Failback bir bakım işlemidir ve bakım gibi planlanmalıdır. Aşağıdaki adımları bir yordam olarak yazıp ekibinle paylaşmanı öneririm; kriz anında düşünmek yerine listeyi takip etmek çok daha güvenlidir.

1. Kök nedeni doğrula. Birincilin neden çöktüğünü biliyor musun? Bilmiyorsan geri dönmek, aynı arızayı yeniden davet etmektir.
2. Donanım ve sistem sağlığını kontrol et. Disk SMART değerleri, bellek testi, sistem kayıtları. Arızanın kalıcı bir donanım sorunu olmadığından emin ol.
3. Veriyi hizala. Yedek üzerinde biriken tüm değişikliklerin birincile aktarıldığını ve çoğaltmanın gecikmesiz çalıştığını doğrula.
4. Yapılandırma farklarını gider. Arıza sırasında yedekte yapılan acil değişiklikler (güvenlik duvarı kuralı, ayar dosyası, sertifika) birincile de uygulanmalı.
5. Düşük trafikli bir zaman seç. Geri dönüş kısa bir kesinti üretir; bunu gece ya da hafta sonu yapmanın maliyeti gündüz yapmanın çok altındadır.
6. Geri dönüşün geri dönüşünü hazırla. Birincile döndükten sonra sorun çıkarsa tekrar yedeğe geçebileceğinden emin ol; yedeği kapatma.
7. İzle ve bekle. Dönüşten sonra en az birkaç saat aktif izleme yap. Hata oranı, yanıt süresi ve kaynak kullanımı normale oturmadan olayı kapatma.
8. Olay kaydını yaz. Ne oldu, ne yapıldı, ne öğrenildi. Bu kayıt bir sonraki olayda en değerli belgen olacak.

Bu listedeki 3. ve 4. adımlar en çok atlanan ama en pahalıya mal olanlardır. Arıza sırasında telaşla yedekte yapılan küçük bir değişikliği birincile taşımayı unutmak, geri döndükten saatler sonra ortaya çıkan ve teşhisi zor bir arıza üretir.

Geri dönüş kararını verirken ne kadar veri kaybını göze alabildiğini de bilmen gerekir; bu eşiği tanımlamak RTO ve RPO yazısının konusudur ve failback planının çıkış noktasıdır.

Uygulama Katmanında Zarif Bozulma#

Fallback kelimesinin ikinci anlamı — alternatif yol — asıl değerini uygulama katmanında gösterir. Buradaki fikir şudur: bir bağımlılık yanıt vermediğinde tüm sistemi durdurmak yerine, o özelliği kapatıp geri kalanını çalışır tutmak. Buna zarif bozulma (graceful degradation) denir.

Somut örnekler: öneri motoru yanıt vermiyorsa ürün sayfası önerileri boş gösterir ama açılır; arama servisi çökerse kategori gezintisi çalışmaya devam eder; kargo API'si yanıt vermiyorsa tahmini teslim tarihi yerine genel bir metin gösterilir. Her durumda kullanıcı bir şey kaybeder ama alışverişini tamamlayabilir.

Web sunucusu katmanında en basit fallback, arka uçların tamamı düştüğünde statik bir bakım sayfası servis etmektir:

upstream uygulama_havuzu {
    server 10.0.0.11:8080 max_fails=3 fail_timeout=15s;
    server 10.0.0.12:8080 max_fails=3 fail_timeout=15s;
}

server {
    listen 80;
    server_name firmaniz.com;

    location / {
        proxy_pass http://uygulama_havuzu;
        # Arka uç hatasını kullanıcıya ham göstermek yerine yakala
        proxy_intercept_errors on;
        error_page 502 503 504 = @bakim;
    }

    location @bakim {
        root /var/www/bakim;
        try_files /index.html =503;
        # Arama motorları bu sayfayı kalıcı sanmasın
        add_header Retry-After 300 always;
    }
}

Buradaki Retry-After başlığı küçük ama önemli bir detaydır: arama motorlarına ve istemcilere durumun geçici olduğunu söyler. Bakım sayfasını 200 koduyla döndürmek ise yaygın ve zararlı bir hatadır — arama motoru o içeriği sitenin gerçek içeriği sanıp indeksler.

Uygulama içi fallback tasarlarken üç kural işine yarar. Birincisi, alternatif yol hızlı başarısız olmalıdır: bir bağımlılığı 30 saniye beklemek, hizmeti kapatmaktan daha kötüdür, çünkü tüm iş parçacıklarını tüketir. Kısa zaman aşımı ve devre kesici (circuit breaker) deseni burada işe yarar. İkincisi, fallback devreye girdiğinde bunu kaydet ve uyarı üret — sessizce çalışan bir fallback, aylardır bozuk olan bir bağımlılığı gizleyebilir. Üçüncüsü, fallback yolunu da test et; hiç denenmemiş bir alternatif yol, gerçekten ihtiyaç duyulduğunda çalışmaz.

Sık Yapılan Hatalar#

Failover'ı test edip failback'i test etmemek. Devretmenin çalıştığını doğrularsın ama geri dönüşü hiç denemezsin. Gerçek olayda geri dönüş sırasında çıkan sorun, asıl arızadan daha uzun bir kesintiye yol açar.

Geri dönüşü otomatikleştirmek. nopreempt yazmadığın bir Keepalived kurulumunda, aralıklı arızalanan bir düğüm sistemi sürekli gidip gelen bir duruma sokar.

Yedeğe geçtikten sonra rahatlamak. Yedeğe geçtiğin an tek düğümlü bir sistemsin. Kök nedeni gidermek artık daha da acildir, daha az değil.

Eski birincili doğrudan açmak. Veritabanı tarafında bu split-brain demektir. Eski birincil her zaman yeni birincilin yedeği olarak yeniden kurulmalıdır.

Bakım sayfasını 200 ile döndürmek. Doğru kod 503'tür ve Retry-After başlığıyla birlikte gönderilmelidir. Aksi halde arama sonuçlarında bakım metnini görürsün.

Fallback'i sessiz bırakmak. Alternatif yol devreye girdiğinde uyarı üretmiyorsa, bozuk bir bağımlılık aylarca fark edilmeden kalabilir ve asıl sorunu ancak fallback de çöktüğünde öğrenirsin.

Arıza sırasındaki değişiklikleri kayıt altına almamak. Telaşla yapılan ayar değişiklikleri geri dönüşte kaybolur ve haftalar sonra açıklanamayan davranışlar olarak geri gelir.

Sıkça Sorulan Sorular#

Failover ve fallback arasındaki temel fark nedir#

Failover, birincil sistem arızalandığında hizmetin yedeğe geçmesidir; acil, otomatik ve hızlı olması gerekir. Fallback ise arıza giderildikten sonra normale dönüş sürecidir — daha kesin adıyla failback. Bu ikincisi acil değildir, planlanabilir ve neredeyse her zaman elle yapılmalıdır. Kısaca failover krizin cevabı, fallback ise krizin sonrasıdır.

Failback otomatik olsun mu#

Altyapı seviyesinde hayır. Otomatik geri dönüş gereksiz bir ikinci kesinti üretir, arıza sebebi devam ediyorsa sistemi iki düğüm arasında gidip gelen bir duruma sokar ve veri katmanında yedekte biriken yazmaların kaybına yol açabilir. Keepalived'de nopreempt, yük dengeleyicilerde ise düğümü elle havuza alma bu yüzden vardır. Uygulama içi alternatif yollar (fallback'in ikinci anlamı) ise tam tersine otomatik olmalıdır.

Failover ne kadar sürede tamamlanmalı#

Katmana göre değişir. Yük dengeleyici arkasındaki bir uygulama düğümünün havuzdan çıkarılması pratikte anlıktır. Sanal IP devretmesi tipik olarak 3-5 saniye sürer. Veritabanı devretmesi, yedeğin yükseltilmesi ve uygulamaların yeni adrese yönelmesiyle birlikte saniyelerden birkaç dakikaya kadar çıkabilir. Hedefini belirlerken toplam kesinti süresinin RTO'nun içinde kalması gerektiğini unutma.

Failover sırasında veri kaybı olur mu#

Çoğaltmanın türüne bağlıdır. Eşzamanlı çoğaltmada yedek düğüm her yazmayı onayladığı için veri kaybı yok denecek kadar azdır, ama her yazma ağ gecikmesi kadar yavaşlar. Eşzamansız çoğaltmada yedek biraz geriden gelir; birincil o pencerede çökerse aradaki işlemler kaybolur. Kabul edilebilir kayıp miktarını RPO olarak tanımlar ve çoğaltma stratejini ona göre seçersin.

Zarif bozulma ile failover aynı şey mi#

Hayır. Failover, aynı hizmeti başka bir bileşen üzerinden tam olarak sürdürmektir; kullanıcı ideal olarak hiçbir fark görmez. Zarif bozulma ise bir bağımlılık kaybolduğunda hizmetin eksik ama çalışır halde devam etmesidir — öneriler görünmez, arama kapalıdır ama sipariş verilebilir. İkisi birbirini tamamlar: failover'ın olmadığı ya da yetmediği yerlerde zarif bozulma toplam kesintiyi çok azaltır.

Geri dönüşü ne zaman yapmalıyım#

Kök nedeni bulup giderdikten, birincilin sağlığını doğruladıktan ve yedekte biriken veriyi hizaladıktan sonra — ve mutlaka düşük trafikli bir zaman diliminde. Acele etmene gerek yok: sistem yedek üzerinde stabil çalışıyorsa günlerce öyle kalabilir. Asıl risk, sorunu tam anlamadan aceleyle geri dönmek ve aynı arızayı bu kez yedeği de kaybetmiş halde yaşamaktır.

Kapanış#

Failover ile fallback'i ayırmak, kelime titizliğinden ibaret değil; iki farklı riski ayrı yönetmenin yoludur. Aklında kalması gereken dört şey var: failover otomatik ve hızlı olmalı, failback elle ve planlı yapılmalı, yedeğe geçtiğin an sistemin tek düğümlü olduğunu unutmamalı ve eski birincili asla olduğu gibi geri açmamalısın. Bir de uygulama içi alternatif yolları sessiz bırakmamalı — devreye girdiklerinde haber vermeyen bir fallback, gizlediği arızayla birlikte büyür.

Bu yordamları kurmak ve düzenli tatbikatla canlı tutmak zaman ister. VDS ve bulut sunucu paketlerimizle yedekli bir ortamı hızlıca kurabilir, geri dönüş sırasında veriye güvenmek için yedekleme hizmetimizi kullanabilirsin. Devretme mekanizmalarının kurulumunu, izlenmesini ve düzenli testlerini bize bırakmak istersen sunucu yönetimi hizmetimiz bu işi baştan sona üstlenir.