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.

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ın: 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 koyun. Mutabakat katmanını (etcd) farklı arıza alanlarına (availability zone) yayılmış tek sayıda üyeyle kurun — 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ı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. Asla elle yazılmış failover script’ine güvenmeyin. “Master’a ping atmıyorsa terfi et” mantığındaki ev yapımı script’ler tam olarak sizin yaşadığınız split-brain’i üretir. Bu çözülmüş bir problem; çö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.