Failover bitti mi, yoksa sadece başladı mı?
Birçok sistem failover olayını “başarılı” diye işaretlediğinde ekip rahatlar. Ama kullanıcı tarafında bağlantı havuzları eski soketleri tutuyor, workerlar yeniden bağlanamıyor veya DNS önbellek davranışı gecikiyorsa etki devam eder.
Bu yüzden failover sonrası ilk kontrol, yalnızca cluster state değil, uçtan uca küçük bir iş akışıdır. Okuma, yazma, kritik transaction ve arka plan işlerinden en az biri test edilmelidir.
- Yeni primary veya yazma uç noktai net mi?
- Uygulama yeni bağlantıya otomatik geçti mi?
- Eski bağlantılar pool içinde takılı kaldı mı?
- Kritik write path gerçekten başarılı mı?
- Kullanıcı etkisi devam ediyor mu, yoksa sadece alarm mı açık kaldı?
İlk kontrol: olay sırası ve bağlantı yolu
Failover sonrası olay sırasını görmek çok önemlidir. Node kaybı mı yaşandı, bakım mı tetikledi, failover kaç saniye sürdü, uç nokta ne zaman güncellendi? Bu bilgi uygulama loglarıyla yan yana konduğunda tablo netleşir.
TürkDB failover sonrası ilk bakış
turkdb cluster get app-db turkdb cluster events app-db --limit 50 turkdb connect app-db --no-tunnel
Bağlantı bilgisini uygulamanın kullandığı DSN ile karşılaştırın. Sorun bazen veritabanında değil, eski uç noktai tutan uygulama yapılandırmasındadır.
Motor tarafında yazma ve replikasyon kontrolü
Her motorun failover sonrası kontrol dili farklıdır. PostgreSQL’de pg_is_in_recovery() yeni nodeun primary olup olmadığını gösterir. MySQL’de read_only ve replication durumu önemlidir. MongoDB’de replica set primary seçimi okunur. Buradaki amaç tek bir komut ezberlemek değil, “şu an nereye yazıyoruz?” sorusunu cevaplamaktır.
PostgreSQL primary kontrolü
SELECT pg_is_in_recovery() AS is_replica; CREATE TABLE IF NOT EXISTS failover_smoke_test ( id bigserial PRIMARY KEY, checked_at timestamptz DEFAULT now() ); INSERT INTO failover_smoke_test DEFAULT VALUES RETURNING id, checked_at;
MySQL yazılabilirlik kontrolü
SHOW VARIABLES LIKE 'read_only'; SHOW VARIABLES LIKE 'super_read_only'; CREATE TABLE IF NOT EXISTS failover_smoke_test ( id BIGINT AUTO_INCREMENT PRIMARY KEY, checked_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ); INSERT INTO failover_smoke_test () VALUES ();
Uygulama reconnect davranışını küçümsemeyin
Failover başarılı olsa bile uygulama tarafındaki pool eski bağlantıları uzun süre taşıyabilir. Bazı driverlar hata alınca yeniden bağlanır, bazıları zaman aşımı bekler, bazı frameworkler ise pool içindeki bozuk bağlantıyı geç temizler.
Bu yüzden failover sonrası uygulama metriklerinde connection error, retry sayısı, p95 gecikme ve worker restart davranışı birlikte izlenmelidir. Gerekiyorsa uygulama poolu kontrollü şekilde yenilenir; ama bunu yaparken olayın veritabanı tarafını örten bir yeniden başlatma dalgasına dönüştürmemek gerekir.
- Connection pool sağlık kontrolü gerçekten yeni bağlantı açıyor mu?
- Driver retry/backoff ayarları çok agresif mi?
- Workerlar aynı anda yeniden bağlanıp yeni primary üzerinde ani yük yaratıyor mu?
- Read replica kullanan servisler doğru read uç noktaine dönüyor mu?
Failover sonrası yedek ve alarm temizliği
Failoverdan sonra “servis geri geldi” demek yetmez. Yedek jobları, PITR penceresi, replikasyon alarmı ve eski primary ile ilgili uyarılar gözden geçirilmelidir. Çünkü HA olayı bazen yedekleme akışını veya bakım planını sessizce etkiler.
TürkDB olay kayıtları ve yedek görünürlüğü burada faydalıdır: failoverdan sonra koruma mekanizmasının hâlâ çalıştığını görmek, asıl güven hissini verir.
Koruma sinyallerini kontrol etme
turkdb backup list app-db turkdb cluster pitr window app-db turkdb cluster events app-db --limit 20