PostgreSQL split-brain'i quorum ve mutabakat ile nasıl önlerim?

Kısa cevap: Split-brain’in tek panzehiri quorum’dur — bir node ancak çoğunluğu elinde tutuyorsa primary olabilir ya da primary kalabilir. Yaşadığınız senaryoda eksik olan tam da buydu.

Kısa cevap

Sorunun kökü şu: bir replica yalnızca yerel bilgiye bakarak (“Master’a ulaşamıyorum, demek ki öldü”) kendini terfi ettirdi. Oysa Master ölmemişti, sadece ağı koptu. İki primary, ayrışan veri. Uygulamanın hangi sunucuya bağlandığını yöneten katmanın kararlarını PgBouncer havuzlama modları kaydında ayrıca ele almıştım; failover o katmanın altındaki topolojiyi değiştirir.

Neden

1. Yerel bilgi bir arıza kanıtı değildir. “Ulaşamıyorum” ile “ölmüş” arasındaki farkı tek bir node’un görmesi mümkün değil; bu ayrımı ancak çoğunluk yapabilir.

2. Ev yapımı failover script’i tam bu hatayı üretir. “Master’a ping atmıyorsa terfi et” mantığı, ağ bölünmesinde iki primary doğurur. Bu çözülmüş bir problem.

3. İzole kalan eski primary yazmaya devam ederse veri ayrışır. Terfiyi engellemek yetmez; eski primary’nin de kendini durdurması gerekir.

Ne yapmalı

1. Çoğunluk olmadan kimse primary olamasın. Failover kararını mutabakatla veren bir yönetici kullanın: Patroni + etcd/Consul. Lider kilidini Raft tutar; yeni primary olabilmek için node’un quorum’dan o kilidi alması gerekir.

2. Eski primary kendini düşürsün (fencing). Patroni’nin varsayılan davranışı net: lider kilidinin güncellenmesi başarısız olduğu anda Postgres derhal demote edilip read-only başlatılır. Yani ağdan izole olan eski Master kendini replica’ya düşürür ve “iki primary aynı anda yazıyor” durumu imkânsızlaşır. (DCS Failsafe Mode açıksa primary, tüm üyelere Patroni REST API üzerinden ulaşabildiği sürece ayakta kalabilir; üyelerden biri cevap vermezse yine demote olur.)

3. Tek sayıda oy veren üye koyun. Mutabakat katmanını (etcd) farklı arıza alanlarına yayılmış tek sayıda üyeyle kurun — 3 ya da 5. Ağ ikiye bölündüğünde net bir çoğunluk tarafı oluşur.

4. Son işlemleri kaybedemiyorsanız senkron replikasyon ekleyin. synchronous_commit ve quorum tabanlı senkron replikasyon ile commit, en az bir replica onaylamadan dönmez. Bedeli gecikme, kazancı sıfıra yakın veri kaybı.

5. Elle yazılmış failover script’ini emekliye ayırın. Çözümü yeniden icat etmeyin.

Sonuç: Ben olsam Patroni + etcd quorum + fencing üçlüsüne geçerim, failover’ı elle yönetmem. Veritabanı operasyonunun derinine sade.dev’de giriyorum; ama tek cümlesi şu: terfi kararı yerel bilgiyle değil, çoğunlukla verilir.