PostgreSQL Replikasyonu: Master-Slave, Streaming Replication ve Read Replicas

Modern kurumsal yazılım mimarisinde PostgreSQL Replikasyonu: Master-Slave, Streaming Replication ve Read Replicas konusu, sistemlerin yüksek eşzamanlılık altında kesintisiz çalışması, veri tutarlılığının korunması ve milisaniyeler seviyesinde yanıt süreleri elde edilmesi açısından kritik bir mühendislik disiplinidir.

Geliştirilen dijital ürünlerin ölçeği arttıkça, geleneksel monolitik alışkanlıklar ve hazır şablon kalıpları yetersiz kalır; bellek sızıntıları (memory leaks), sorgu kilitlenmeleri (deadlocks) ve render darboğazları ortaya çıkar. Bu makalede, üretim ortamında doğrudan test edilmiş mimari prensipleri ve en iyi pratikleri adım adım inceliyoruz.

1. Temel Problem ve Mimari Arka Plan

Büyük ölçekli sistemlerde PostgreSQL Replikasyonu: Master-Slave, Streaming Replication ve Read Replicas yaklaşımına ihtiyaç duyulmasının temel nedenleri şunlardır:

1. Kaynak Verimliliği & Düşük Gecikme: Yanlış kurgulanan veri akışları sunucu CPU ve RAM tüketimini katlarken, kullanıcı tarafında First Contentful Paint (FCP) ve Time to Interactive (TTI) sürelerini doğrudan olumsuz etkiler.
2. Uçtan Uca Tip Güvenliği & Hata İzolasyonu: Çalışma zamanında (runtime) ortaya çıkan beklenmedik null veya undefined istisnaları, canlı ortam kesintilerinin bir numaralı sebebidir.
3. Ölçeklenebilirlik & Bakım Kolaylığı: İş mantığının (business logic) altyapı bağımlılıklarından temiz biçimde ayrıştırılması, ekibin gelecekteki refactoring süreçlerini güvenle yönetmesini sağlar.

2. Derinlemesine Çalışma Mantığı ve Mimari Prensipler

Aşağıdaki mimari diyagram ve prensipler, Veritabanı alanındaki modern standartları özetlemektedir:

• Sıfır Güven (Zero-Trust) Doğrulama: Dış dünyadan gelen her istek, API ağ geçidinde veya sunucu bileşeni katmanında şema denetimine tabi tutulur.
• Asenkron Kuyruk & İşleme: Yoğun I/O gerektiren işlemler ana iş parçacığını (main thread / event loop) bloke etmeden arka plan kuyruklarına devredilir.
• Önbellek Hiyerarşisi (Tiered Caching): Bellek içi (L1 / In-Memory), Redis (L2 / Distributed) ve CDN Edge (L3) seviyelerinde katmanlı önbellek politikası uygulanır.

3. Üretim Seviyesinde Kod Örneği

Aşağıdaki blok, Veritabanı süreçlerinde doğrudan kullanılabilecek, üretim standartlarında tip güvenli ve hata yönetimli bir kod örneğini içermektedir:

-- PostgreSQL Replikasyonu: Master-Slave, Streaming Replication ve Read Replicas — İleri Düzey Veritabanı ve İndeksleme Optimizasyonu
 
-- 1. Partitioned Tablo Tasarımı (Zaman veya Organizasyon Bazlı Bölümleme)
CREATE TABLE IF NOT EXISTS audit_logs (
    id UUID DEFAULT gen_random_uuid(),
    org_id UUID NOT NULL,
    actor_id UUID NOT NULL,
    action_type VARCHAR(64) NOT NULL,
    payload JSONB NOT NULL DEFAULT '{}'::jsonb,
    ip_address INET,
    created_at TIMESTAMPTZ NOT NULL DEFAULT clock_timestamp(),
    PRIMARY KEY (id, created_at)
) PARTITION BY RANGE (created_at);
 
-- 2. Aylık Otomatik Bölümler (Partitions)
CREATE TABLE IF NOT EXISTS audit_logs_2026_08
PARTITION OF audit_logs
FOR VALUES FROM ('2026-08-01 00:00:00+00') TO ('2026-09-01 00:00:00+00');
 
-- 3. Bileşik B-Tree & GIN İndeksleri
CREATE INDEX IF NOT EXISTS idx_audit_logs_org_created
ON audit_logs (org_id, created_at DESC);
 
CREATE INDEX IF NOT EXISTS idx_audit_logs_payload_gin
ON audit_logs USING GIN (payload jsonb_path_ops);
 
-- 4. Sorgu Planı ve Analizi
EXPLAIN (ANALYZE, BUFFERS, VERBOSE)
SELECT id, action_type, payload->>'status' AS status, created_at
FROM audit_logs
WHERE org_id = 'a0eebc99-9c0b-4ef8-bb6d-6bb9bd380a11'
  AND created_at >= NOW() - INTERVAL '7 days'
ORDER BY created_at DESC
LIMIT 50;

4. Canlı Ortamda Karşılaşılan Edge Case'ler ve Darboğaz Yönetimi

Üretim ortamına canlıya çıkarken dikkat edilmesi gereken kritik senaryolar:

• Yarış Durumları (Race Conditions): Eşzamanlı gelen mutasyon isteklerinde veritabanı kilitleri (SELECT FOR UPDATE) veya dağıtık Redis kilitleri (Redlock) kullanarak mükerrer veri yazımı engellenmelidir.
• Bağlantı Sızıntıları (Connection Leaks): Veritabanı ve HTTP bağlantı havuzlarının (pool size) doğru yapılandırılması ve boşta kalan bağlantıların zaman aşımına uğratılması gerekir.
• Zarif Kapanma (Graceful Shutdown): Sunucu kapatılırken veya yeni dağıtım (deployment) yapılırken mevcut aktif işlemlerin tamamlanması için SIGTERM ve SIGINT sinyalleri dinlenmelidir.

5. Karşılaştırmalı Performans ve Karar Matrisi

6. Mühendislik Çıkarımları ve Dağıtım Kontrol Listesi

1. Otomasyon & CI/CD: Her kod değişikliğinde tip kontrolü, linter denetimi ve birim testler otomatik koşmalıdır.
2. Gözlemlenebilirlik (Observability): Canlı sistem metrikleri Prometheus, Sentry ve yapılandırılmış loglar üzerinden anlık izlenmelidir.
3. Geriye Dönük Uyumluluk: Veritabanı şema migrasyonlarında Expand and Contract deseni kullanılarak sıfır kesintili güncelleme sağlanmalıdır.

Bu mimariyi kendi şirketinizin projelerinde hayata geçirmek, kurumsal özel yazılım veya teknik danışmanlık almak için İletişim sayfası üzerinden doğrudan bana ulaşabilirsiniz.