Replikasyon Mimarisi: Fiziksel ve Mantıksal Seçim Rehberi
- 18 Ağu
- 4 dakikada okunur
PostgreSQL projelerinde yüksek kullanılabilirlik (High Availability), felaket kurtarma (Disaster Recovery) ve ölçeklenebilirlik mimarilerini kurgularken vermeniz gereken en kritik karar, veri taşıma yöntemini seçmektir. PostgreSQL, verileri sunucular arasında taşımak için iki temel yaklaşım sunar: Fiziksel (Streaming) Replikasyon ve Mantıksal (Logical) Replikasyon.
Her iki yöntemin de veri tabanı motoru seviyesinde çalışma biçimleri, sınırları ve getirdiği avantajlar tamamen farklıdır. Yanlış mimari seçimi; ilerleyen süreçte yetersiz performansa, operasyonel darboğazlara veya geri dönülmesi zor şema yönetimi krizlerine yol açabilir.
Bu rehberde; daha önceki yazılarımızda detaylandırdığımız her iki mimarinin temel dinamiklerini karşılaştıracak, karar vermenizi kolaylaştıracak senaryoları inceleyecek ve doğru seçimi yapmanızı sağlayacak bir karar matrisi sunacağız.
1. Mimarilerin Çalışma Prensipleri ve Farkları
Doğru kararı verebilmek için öncelikle bu iki teknolojinin arka planda veriyi nasıl ele aldığını anlamamız gerekir.
A. Fiziksel Replikasyon (Fiziksel Blok Seviyesi)
Fiziksel replikasyon, veri tabanının disk üzerindeki fiziksel yapısının bayt düzeyinde (byte-by-byte) birebir kopyalanmasıdır. PostgreSQL’in ürettiği WAL (Write-Ahead Log) kayıtları, yedek sunucuya (Standby) gönderilir ve yedek sunucu bu logları doğrudan disk bloklarına (pages) yazar.
Çalışma Biçimi: Sunucu, veri tabanı nesnelerinin (tablo, indeks, şema) ne olduğunu bilmeden sadece diskteki 8 KB'lık veri bloklarındaki değişimleri aktarır ve uygular.
Doğal Özelliği: Yedek sunucu, ana sunucunun (Primary) karbon kopyasıdır. Bu nedenle yedek sunucu yalnızca "Okunabilir" (Read-Only) modda kalmak zorundadır, üzerine doğrudan yazma yapılamaz.
B. Mantıksal Replikasyon (Nesne ve Satır Seviyesi)
Mantıksal replikasyon, verileri disk blokları üzerinden değil, SQL seviyesindeki veri manipülasyonları (INSERT, UPDATE, DELETE) üzerinden taşır. Primary sunucudaki WAL kayıtları çözümlenerek (Logical Decoding) mantıksal bir veri akışına dönüştürülür ve hedef sunucudaki tablolara standart SQL komutları gibi uygulanır.
Çalışma Biçimi: Yayıncı/Abone (Publish/Subscribe) modelini kullanır. Sadece seçilen belirli tabloların veya şemaların verileri aktarılır.
Doğal Özelliği: Hedef veri tabanı bağımsız bir veri tabanıdır. Replikasyon akışı devam ederken, hedef veri tabanına dışarıdan doğrudan yazma (Read-Write) işlemleri de yapılabilir.
2. Detaylı Karşılaştırma Matrisi
Değerlendirme Kriteri | Fiziksel Replikasyon (Physical) | Mantıksal Replikasyon (Logical) |
Kopyalama Birimi | Tüm PostgreSQL Kümesi (Cluster) | Seçilen Tablolar veya Şemalar |
Hedef Sunucu Durumu | Sadece Okunabilir (Read-Only) | Yazılabilir ve Okunabilir (Read-Write) |
PostgreSQL Sürümleri | Ana ve Yedek sürümleri birebir aynı olmalı | Farklı büyük (Major) sürümler arasında çalışabilir |
İşletim Sistemi / CPU | OS, CPU mimarisi ve glibc sürümü aynı olmalı | Farklı OS ve mimariler arası çalışabilir (Cross-platform) |
DDL (Şema) Değişiklikleri | Otomatik olarak replike edilir | Otomatik replike edilmez, manuel yönetim gerekir |
Indeks Replikasyonu | Indeksler fiziksel olarak kopyalanır | Sadece veri kopyalanır, indeksler hedefte tekrar oluşturulur |
Büyük Nesneler (LOB) | Tamamen desteklenir | Desteklenmez |
Gecikme (Lag) Maliyeti | Çok düşük CPU ve ağ maliyeti | Çözümleme (Decoding) nedeniyle biraz daha yüksek CPU maliyeti |
Çakışma (Conflict) Riski | Yoktur (Salt okunurdur) | Yüksektir (Hedefte aynı Primary Key ile yazma yapılırsa durur) |
3. Karar Verme Senaryoları (Hangi Durumda Hangisi?)
Seçim yaparken uygulamanızın ve iş modelinizin gereksinimlerini aşağıdaki senaryolara göre eşleştirebilirsiniz:
Senaryo A: Felaket Kurtarma (Disaster Recovery) ve Yüksek Kullanılabilirlik (HA)
Gereksinim: Ana sunucunun çökmesi durumunda sıfır veya sıfıra yakın veri kaybı ile yedek sunucuyu devreye almak (Failover). Şema değişikliklerinin (DDL) anında yedeğe yansıması.
Karar: Fiziksel Replikasyon.
Neden? Fiziksel replikasyon tüm veri tabanını, indeksleri ve şema yapılarını (tablo ekleme/çıkarma, kolon tipi değiştirme) ekstra bir yönetimsel efor gerektirmeden birebir kopyalar. En güvenilir HA mimarileri fiziksel replikasyon üzerine kurulur.
Senaryo B: Raporlama ve Veri Ambarı (Data Warehousing)
Gereksinim: Üretim (Production) sistemindeki devasa veri tabanından sadece siparisler ve musteriler tablolarının analiz edilmek üzere bir analitik sunucuya taşınması. Analitik sunucuda ise raporlama ekiplerinin kendi geçici tablolarını ve indekslerini oluşturabilmesi.
Karar: Mantıksal Replikasyon.
Neden? Fiziksel replikasyon tüm veri tabanını kopyalamaya zorlar ve hedefi salt okunur yapar. Mantıksal replikasyon ile sadece ihtiyaç duyulan tabloları seçebilir ve hedef veri tabanını raporlama yazmaları için özgürce kullanabilirsiniz.
Senaryo C: Sıfır Kesinti ile Sürüm Yükseltme (Zero-Downtime Major Upgrade)
Gereksinim: Canlıda çalışan PostgreSQL 12 sürümündeki sistemi, uygulamayı kapatmadan veya çok az bir kesintiyle (birkaç saniye) PostgreSQL 17 sürümüne yükseltmek.
Karar: Mantıksal Replikasyon.
Neden? Fiziksel replikasyon farklı PostgreSQL majör sürümleri arasında çalışmaz. Mantıksal replikasyon ise sürümler arası veri aktarabildiği için, yeni sürüme kurulan boş veri tabanına canlı veriyi akıtarak geçiş (switchover) süresini minimuma indirir.
Senaryo D: Coğrafi Dağıtık ve Çok Merkezli (Multi-Region) Yapılar
Gereksinim: Türkiye, Almanya ve ABD'deki yerel ofislerin kendi yerel veri tabanlarına yazma yapabilmesi, ancak günün sonunda belirli kritik tabloların merkez veri tabanında toplanması (Consolidation).
Karar: Mantıksal Replikasyon.
Neden? Fiziksel replikasyon tek yönlüdür ve hedefi kilitleyip salt okunur yapar. Mantıksal replikasyon ise esnek Publish/Subscribe yapısı sayesinde çoklu veri tabanından tek bir merkeze veri toplama (hub-and-spoke) mimarilerine izin verir.
4. Mimari Karar Akış Şeması (Decision Flow)
Replikasyon stratejinizi belirlerken kendinize şu soruları sırasıyla sorabilirsiniz:
Hedef veri tabanının üzerine yazma yapılması (Read-Write) gerekiyor mu?
Evet ise: Mantıksal Replikasyon kullanmalısınız.
Hayır ise: Soru 2'ye geçin.
Sadece belirli tabloları mı kopyalamak istiyorsunuz?
Evet ise: Mantıksal Replikasyon kullanmalısınız.
Hayır (Tüm cluster) ise: Soru 3'e geçin.
Kaynak ve hedef sunucuların PostgreSQL majör sürümleri veya işletim sistemleri farklı mı?
Evet ise: Mantıksal Replikasyon kullanmalısınız.
Hayır ise: Fiziksel Replikasyon kullanmalısınız.
5. Hibrit Yaklaşım (En İyi Pratik)
Modern ve büyük ölçekli altyapılarda genellikle bu iki yöntem birbirini dışlayan çözümler olarak değil, birlikte (hibrit) kullanılır:
Örnek Altyapı Mimarisi:Primary Sunucu (Read-Write): Ana veri tabanı.Standby Sunucu (Read-Only - Fiziksel Replikasyon ile bağlı): Ana sunucunun hemen yanında, sıfır veri kaybı hedefiyle çalışan felaket kurtarma ve yüksek erişilebilirlik (HA) yedeği.Raporlama / BI Sunucusu (Read-Write - Mantıksal Replikasyon ile bağlı): Primary sunucudan sadece iş analitiği için kritik olan 10-15 tablonun mantıksal olarak aktarıldığı, veri analistlerinin üzerinde rapor yazabildiği bağımsız sunucu.
Bu hibrit yapı sayesinde hem veri güvenliğinizi ve sistem kararlılığınızı fiziksel replikasyonla en üst düzeyde korur hem de veri analitiği ve esnek veri paylaşımı ihtiyaçlarınızı mantıksal replikasyonun sunduğu özgürlükle çözersiniz.
