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 senaryoda eksik olan tam da buydu.

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.

1. Çoğunluk olmadan kimse primary olamasın. Failover kararını mutabakatla veren bir yönetici kullan: Patroni + etcd/Consul. Lider kilidini Raft tutar; yeni primary olabilmek için node’un quorum’dan o kilidi alması gerekir. Çoğunluğa erişemeyen bir node terfi edemez.
2. Eski primary kendini düşürsün (fencing). Ağdan izole olan eski Master, etcd’deki kilidini yenileyemediği için süresi dolar ve kendini otomatik olarak replica’ya düşürür. Buna fencing/STONITH denir; “iki primary aynı anda yazıyor” durumunu fiziksel olarak imkânsızlaştırır.
3. Tek sayıda oy veren üye koy. Mutabakat katmanını (etcd) farklı arıza alanlarına (availability zone) yayılmış tek sayıda üyeyle kur — 3 ya da 5. Ağ ikiye bölündüğünde net bir çoğunluk tarafı oluşur; azınlık tarafı yazmayı durdurur.
4. Son işlemleri kaybedemiyorsan senkron replikasyon ekle. 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. Asla elle yazılmış failover script’ine güvenme. “Master’a ping atmıyorsa terfi et” mantığındaki ev yapımı script’ler tam olarak senin yaşadığın split-brain’i üretir. Bu çözülmüş bir problem; çözümü yeniden icat etme.

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.