# 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://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.

## 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](/tr/sor-bakalim/pgbouncer-session-transaction-statement-modu-ve-prepared-statement/) 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 (örneğin `synchronous_standby_names = 'ANY 1 (r1, r2)'`) commit, listedeki replica'lardan en az biri 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.

## İ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://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://muhammetsafak.com/tr/sor-bakalim/veritabani-deadlock-tespiti-ve-onleme-kurallari/) — Sor Bakalım
- [Heap erişimini önlemek ve index-only scan almak için covering index'e (INCLUDE) ne zaman geçmeliyim?](https://muhammetsafak.com/tr/sor-bakalim/index-only-scan-covering-indexe-ne-zaman-gecmeliyim/) — Sor Bakalım