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

> Failover'ı elle yazmayın: Patroni + etcd ile terfiyi quorum'a bağlayın, çoğunluktan kopan eski primary fencing ile kendini replica'ya düşürsün.

- Soruldu: 2026-05-26
- Yanıtlandı: 2026-05-29
- Soran: Volkan
- Etiketler: dayaniklilik, postgresql, veritabani
- Kaynak: https://www.muhammetsafak.com.tr/sor-bakalim/postgresql-split-brain-quorum-ve-mutabakat-ile-onlemek/
- Dil: tr-TR
- Yazar: Muhammet Şafak

---
**Soru:** PostgreSQL kümemizde bir Master ve iki Read-Replica var. Master ile replica'lar arasındaki ağ anlık koptu ama replica'lar kendi aralarında konuşabiliyordu. Bir replica kendini yeni Master ilan etti; bu sırada eski Master da ayaktaydı ve yazma almaya devam etti — veri ikiye bölündü.

Bu split-brain'i önlemek için quorum mekanizması ve Raft/Paxos tabanlı mutabakat altyapıda nasıl konumlanmalı?


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.

## İlgili Yazılar

- [PostgreSQL Her Şeye Yeter mi?](https://sade.dev/tr/journal/postgresql-her-seye-yeter-mi) — sade.dev
- [WAL arşivleme ve PITR ile felaketten saniyeler öncesine nasıl dönerim?](https://www.muhammetsafak.com.tr/sor-bakalim/veritabani-pitr-ve-wal-arsivleme-ile-felaket-oncesine-donmek/) — Sor Bakalım
- [Veritabanı deadlock'larını önlemek için hangi kurallara dikkat etmeliyim?](https://www.muhammetsafak.com.tr/sor-bakalim/veritabani-deadlock-tespiti-ve-onleme-kurallari/) — Sor Bakalım
- [Sadece 'pending' satırları taranan bir kuyruk tablosunda partial index kullanmalı mıyım?](https://www.muhammetsafak.com.tr/sor-bakalim/sadece-pending-satirlari-taranan-bir-kuyruk-tablosunda-partial-index-kullanmali-miyim/) — Sor Bakalım