MySQL ve PostgreSQL Ekosistemlerinde Replikasyon ve Yüksek Erişilebilirlik Mimarileri
Replikasyon modelleri, yüksek erişilebilirlik kümeleri ve afet kurtarma mimarileri RPO, RTO ve tutarlılık hedeflerine göre karşılaştırması
Bir veri tabanının kopyasını farklı bir sunucuda tutmak tek başına yüksek erişilebilirlik (High Availability - HA) sağlamaz. Replikasyon veriyi aktarırken, yüksek erişilebilirlik mimarisi arızayı algılar, doğru kopyayı seçer, eski yazma noktasını devreden çıkarır ve istemci trafiğini yeni düğüme yönlendirir. Afet kurtarma (Disaster Recovery - DR) ise çoğunlukla daha uzak bir coğrafi bölgede, daha esnek kurtarma hedefleriyle çalışan bağımsız bir katmandır.
MySQL ile PostgreSQL mimarilerini karşılaştırırken üç temel soruyu birbirinden ayırmak gerekir:
- Veri nasıl aktarılıyor? İkili günlük (binary log - binlog), fiziksel önceden yazma günlüğü (Write-Ahead Logging - WAL) veya mantıksal veri akışı yöntemleri kullanılır.
- Kesinti anında yük devretme kararını hangi mekanizma veriyor? MySQL Group Replication, Galera çoğunluk (quorum) mekanizması veya Patroni ile dağıtık yapılandırma deposu (Distributed Configuration Store - DCS) seçenekleri devreye girer.
- İstemci uygulamaları yeni yazma noktasını nasıl buluyor? Veri tabanı yönlendiricisi (MySQL Router), vekil sunucular (proxy), yük dengeleyiciler veya servis keşif araçları bu görevi üstlenir.
Bu incelemede MySQL 8.4 ve PostgreSQL 18 sürümlerinin güncel terminolojisi ve özellikleri temel alınmıştır. Sürüm yükseltmelerinde özellik ve uyumluluk tabloları ayrıca doğrulanmalıdır.
1. RPO, RTO ve tutarlılık hedeflerinin veri güvenliğindeki önemi
Yüksek erişilebilirlik tasarımlarında kurumun veri kaybı toleransı ile kesinti süresi beklentilerinin en başta netleştirilmesi gerekir.
- Hedeflenen kurtarma noktası (Recovery Point Objective - RPO), olası bir kesinti anında kabul edilebilecek maksimum veri kaybı miktarını ifade eder.
- Hedeflenen kurtarma süresi (Recovery Time Objective - RTO), servislerin arıza sonrasında yeniden çalışır duruma gelmesi gereken süreyi tanımlar.
- Okuma tutarlılığı, ikincil sunucular üzerinden yapılan bir sorgunun en güncel yazma işlemini yansıtma güvencesini belirler.
- Yazma sürekliliği, ağ izolasyonu senaryolarında sistemin yeni yazma isteklerini karşılamaya devam etme yeteneğini gösterir.
Ağ bölünmesi senaryolarında tutarlılık ile erişilebilirlik arasındaki zorunlu tercih CAP teoremiyle açıklanır. Normal çalışma şartlarındaki işlem onay (commit) gecikmelerini değerlendirirken ise PACELC yaklaşımı daha açıklayıcıdır çünkü ağ bölünmesi bulunmadığında dahi uzak bir düğümden onay beklemek doğal bir gecikmeye yol açar.
Sıfır veri kaybı (sıfır RPO) hedefi tek bir yazılım özelliği veya parametresi değil, uçtan uca tasarlanan bir mimari kurgunun sonucudur. Bu hedefe ulaşmak için işlem onayının kapsamı, hangi ikincil sunucunun birincil role terfi edeceği, düğüm izolasyonu (fencing), disk kalıcılık ayarları ve yük devretme (failover) adımları birlikte ele alınmalıdır.
2. Yerleşik replikasyon modellerinin özellikleri ve ayrıştığı noktalar
Veri tabanlarının sunduğu yerleşik replikasyon yetenekleri, iş yükünün veri güvenliği ve gecikme toleransına göre yapılandırılır.
MySQL tarafındaki klasik replikasyon, ana sunucudaki değişiklikleri ikili günlük olayları biçiminde ikincil sunuculara ulaştırır. İkili günlükler satır, ifade veya karma formatta tutulabildiği için bu yapı blok replikasyonu olarak nitelendirilemez. PostgreSQL fiziksel replikasyonu, önceden yazma günlüğü kayıtlarını veri tabanı kümesinin tamamı için fiziksel düzeyde kopyalar. PostgreSQL mantıksal replikasyonu (logical replication) ise yayın ve abonelik (publication/subscription) mimarisi üzerinden satır değişikliklerini belirlenen tablo, satır veya sütun bazında filtreleyerek aktarır.
Temel replikasyon yöntemlerinin karşılaştırılması
Farklı replikasyon modellerinin sağladığı veri güvenliği ile gecikme dengesi operasyonel hedeflere göre değişiklik gösterir.
| Kriter | MySQL Asenkron | MySQL Yarı Senkron | PostgreSQL Fiziksel Asenkron | PostgreSQL Fiziksel Senkron | PostgreSQL Mantıksal |
|---|---|---|---|---|---|
| Aktarılan veri | Çoğunlukla satır tabanlı ikili günlük olayları | Asenkron model ile aynı ikili günlük akışı | Fiziksel WAL kayıtları | Fiziksel WAL kayıtları | Mantıksal satır değişiklikleri |
| Kapsam | Filtrelerle veri tabanı veya tablo seçilebilir, dikkatli mimari tasarım gerektirir | Asenkron model ile aynı filtreleme yapısına sahiptir | Veri tabanı kümesinin tamamını kapsar | Veri tabanı kümesinin tamamını kapsar | Yayın tanımıyla tablo, satır veya sütun filtresi uygulanabilir |
| İşlem onayı bekleme noktası | Yalnızca ana sunucudaki yerel işlem onayını bekler | Belirlenen sayıda ikincil sunucunun olayı aktarım günlüğüne yazıp diske kaydettiğine dair onayı bekler, işlemin uygulanmasını beklemez | Yalnızca birincil sunucudaki yerel işlem onayını bekler | Yapılandırılan seviyeye göre ikincil sunucunun yazma, diske boşaltma veya uygulama onayını bekler | Varsayılan olarak asenkrondur, abone sunucu istenirse senkron yedek olarak yapılandırılabilir |
| Yük devretmede RPO hedefi | Replikasyon gecikmesi kadar veri kaybı riski barındırır | Asenkron modele göre daha düşüktür, zaman aşımı durumunda asenkron moda geçebilir | Replikasyon gecikmesi kadar veri kaybı riski barındırır | Doğru senkron sunucu seçildiğinde onaylanmış işlemler için sıfır veri kaybı sağlar | Asenkron kullanımda replikasyon gecikmesi kadar kayıp riski vardır, abonelik yük devretme planı gerektirir |
| İkincil sunucuda güncel okuma garantisi | Sağlanmaz | Sağlanmaz, aktarım günlüğüne yazma onayı verinin işlendiğini göstermez | Sağlanmaz | Uygulama seviyesinde senkronizasyon seçilirse işlem görünür olana kadar bekletilebilir | Veri uygulama gecikmesine bağlı olarak değişkenlik gösterir |
| Şema ve DDL yönetimi | Veri tanımlama dili (DDL) komutları ikili günlük üzerinden replike edilir | Asenkron model ile aynı biçimde DDL komutlarını replike eder | Fiziksel düzeyde tüm şema değişikliklerini doğrudan yansıtır | Fiziksel düzeyde tüm şema değişikliklerini doğrudan yansıtır | Şema ve DDL komutları replike edilmez, sayaçlar ve büyük nesneler ayrı süreçlerle yönetilir |
| Sürüm ve platform esnekliği | Uyumluluk matrisine bağlı olarak kontrollü sürüm yükseltmelerine izin verir | Asenkron model ile aynı yükseltme kurallarına tabidir | Farklı ana sürümler arasında kullanılamaz, aynı işletim sistemi mimarisini gerektirir | Farklı ana sürümler arasında kullanılamaz, aynı işletim sistemi mimarisini gerektirir | Farklı ana sürümler ve işletim sistemleri arasında kesintisiz veri göçü sağlar |
| Öne çıkan kullanım alanı | Okuma kopyaları, raporlama altyapıları ve düşük maliyetli afet kurtarma ortamları | Aynı veri merkezinde düşük veri kaybı hedefleyen altyapılar | Yedek sunucular, okuma ölçekleme ve zaman noktasına kurtarma (Point-in-Time Recovery - PITR) altyapıları | Sıfır veri kaybı hedefleyen aynı veri merkezindeki yüksek erişilebilirlik kümeleri | Seçici veri dağıtımı, veri göçü (migration), konsolidasyon ve ana sürüm yükseltme projeleri |
MySQL yarı senkron replikasyonunda kaynak sunucu, en az bir ikincil sunucunun işlemi teslim alıp aktarım günlüğüne (relay log) güvenle kaydettiğini doğrular, fakat işlemin ikincil sunucu üzerinde fiilen uygulanmasını beklemez. Tanımlanan zaman aşımı süresi aşıldığında sistem otomatik olarak asenkron moda geçebilir. Bu nedenle yarı senkron çalışma modelinin tek başına mutlak veri güvenliği sağladığı varsayımı yanıltıcı olabilir.
PostgreSQL tarafında senkronluk seviyesi daha esnek parametrelerle yönetilir. synchronous_standby_names parametresiyle onay sürecine katılacak yedek sunucular belirlenirken, synchronous_commit parametresiyle onayın ağdan alınma, diske yazılma veya veriye uygulanma aşamalarından hangisinde bekleneceği tayin edilir. Senkron çalışma modeli işlem onay adımlarına en az bir ağ gidiş dönüş süresi eklediği için bu gecikme mimari tasarımda mutlaka hesaba katılmalıdır.
Mantıksal replikasyon yöntemi fiziksel yüksek erişilebilirliğin doğrudan bir alternatifi değildir. Bu modelde şema ve DDL yönetimi harici adımlarla yürütülmeli, sayaç (sequence) değerleri yük devretme öncesinde eşitlenmeli ve kısıt çatışmaları dikkatle ele alınmalıdır. PostgreSQL sürümlerindeki mantıksal yuva senkronizasyon yetenekleri gelişmiş olsa da, olası yük devretmelerde aboneliklerin yeni ana sunucuya yönlendirilmesi ayrıntılı bir geçiş planı gerektirir.
3. Aynı veri merkezinde yüksek erişilebilirlik mimarileri
Donanım, işletim sistemi veya ağ düzeyindeki yerel arızalarda iş sürekliliğini korumak için kanıtlanmış kümeleme mimarilerinden yararlanılır.
InnoDB Cluster, Galera ve Patroni çözümlerinin karşılaştırılması
Farklı veri tabanı platformlarında lider seçimi, veri tutarlılığı ve istemci yönlendirme mekanizmaları kurumsal gereksinimlere göre değerlendirilir.
| Kriter | MySQL InnoDB Cluster | Percona XtraDB Cluster (PXC) | MariaDB Galera Cluster | PostgreSQL ve Patroni |
|---|---|---|---|---|
| Temel bileşenler | MySQL Group Replication, MySQL Shell AdminAPI ve MySQL Router | Percona Server, Galera/wsrep eklentisi ve durum aktarım araçları | MariaDB Server, Galera/wsrep eklentisi ve durum aktarım araçları | PostgreSQL fiziksel akış replikasyonu, Patroni yönetim katmanı ve DCS |
| Varsayılan mimari | Tek birincilli yapı, çok birincilli seçenek mevcuttur | Çok birincilli yazma yeteneği | Çok birincilli yazma yeteneği | Tek birincilli mimari |
| Replikasyon modeli | İşlem sıralama ve sertifikasyon tabanlı grup replikasyonu | Sertifikasyon tabanlı ve neredeyse senkron yazma kümesi replikasyonu | Sertifikasyon tabanlı ve neredeyse senkron yazma kümesi replikasyonu | Asenkron veya senkron fiziksel WAL akışı |
| Karar ve çoğunluk mekanizması | Group Replication bünyesindeki Paxos tabanlı koordinasyon ve çoğunluk mekanizması | Galera birincil bileşen kuralı ve çoğunluk mekanizması | Galera birincil bileşen kuralı ve çoğunluk mekanizması | Patroni DCS üzerinde süreli lider kilidi kullanır, konsensüs mekanizmasını etcd veya Consul katmanı sağlar |
| Yazma noktası | Varsayılan olarak tek birincil sunucu | Tüm düğümler doğrudan yazma isteği kabul edebilir | Tüm düğümler doğrudan yazma isteği kabul edebilir | Yalnızca tek birincil sunucu |
| Yatay yazma ölçekleme | Çok birincilli yapıda dahi çakışma ve sertifikasyon maliyeti bulunur | Genel amaçlı yatay yazma ölçekleme sunmaz, her yazma işlemi tüm kümeye iletilir | Genel amaçlı yatay yazma ölçekleme sunmaz, her yazma işlemi tüm kümeye iletilir | Yerleşik olarak yatay yazma ölçekleme sağlamaz |
| Yük devretme davranışı | İkincil sunucu otomatik olarak birincil role terfi eder | Klasik birincil seçimi bulunmaz, vekil sunucu trafiği çoğunlukta kalan sağlıklı düğüme yönlendirir | Klasik birincil seçimi bulunmaz, vekil sunucu trafiği çoğunlukta kalan sağlıklı düğüme yönlendirir | En güncel yedek sunucu lider kilidini devralarak otomatik terfi eder |
| Bölünmüş beyin savunması | Çoğunluk kuralı geçerlidir, üç üyeli yapıda bir düğüm arızası tolere edilir | Birincil bileşen kuralı uygulanır, azınlıkta kalan taraf yazma işlemlerini durdurur | Birincil bileşen kuralı uygulanır, azınlıkta kalan taraf yazma işlemlerini durdurur | DCS lider kilidi, rol düşürme ve altyapı düzeyinde düğüm izolasyonu ile korunur |
| İstemci yönlendirmesi | Doğrudan ürün ailesi içindeki MySQL Router bileşeniyle sağlanır | Genellikle ProxySQL veya HAProxy katmanıyla yürütülür | Genellikle MaxScale, ProxySQL veya HAProxy ile yürütülür | Patroni REST sağlık kontrolünü izleyen HAProxy veya Envoy yapılarıyla sağlanır, PgBouncer ile bağlantı havuzu desteklenir |
| Yeni düğüm hazırlama | Klon eklentisi, dağıtık kurtarma ve AdminAPI araçlarıyla gerçekleştirilir | Kademeli durum aktarımı veya tam durum aktarımı ile yürütülür | Kademeli durum aktarımı veya tam durum aktarımı ile yürütülür | pg_basebackup veya pgBackRest gibi fiziksel yedekleme araçlarıyla sağlanır |
| Geniş alan ağı uyumu | Küme üyeleri arasında düşük ağ gecikmesi hedeflenir | Yüksek ağ gecikmesi işlem onay sürelerini ve akış kontrolünü doğrudan etkiler | Yüksek ağ gecikmesi işlem onay sürelerini ve akış kontrolünü doğrudan etkiler | Senkron yedek uzak ağdaysa gecikme artar, bu nedenle uzak düğümler genellikle asenkron yapılandırılır |
| Operasyonel profil | MySQL ekosisteminde en bütünleşik yönetim deneyimini sunar | MySQL uyumlu Galera altyapısı ve gelişmiş kurumsal yönetim araçları sağlar | MariaDB ekosisteminin yerleşik özelliklerini ve Galera yeteneklerini bir araya getirir | Modüler ve esnek bir yapı sunar, DCS ve vekil sunucu bileşenleri bağımsız olarak işletilir |
MySQL InnoDB Cluster mimarisi
Harici bir orkestrasyon aracına ihtiyaç duymadan, MySQL’in kendi bileşenleriyle kararlı bir küme yapısı oluşturulabilir.
InnoDB Cluster çözümü, Group Replication yeteneklerini MySQL Shell AdminAPI ve MySQL Router ile bir araya getirir. Çevrimiçi işlem iş yüklerinde operasyonel sadelik adına genellikle tek birincilli (single-primary) model tercih edilir. Group Replication çok birincilli modda çalışabilse de, eşzamanlı çakışan işlemlerde geri dönüş senaryosu (rollback) riski doğabileceğinden her iş yükü yatay yazma ölçeklemesinden verim sağlayamaz.
Grup replikasyonu çoğunluk ilkesiyle çalışır ve bir sunucu arızasını kesintisiz tolere etmek adına en az üç oy veren üyeye ihtiyaç duyar. Yeni birincil sunucu seçildiğinde birikmiş işlemler uygulanmadan trafiğin açılmasını engellemek ve güncel olmayan okuma riskini bertaraf etmek amacıyla group_replication_consistency seviyeleri dikkatle yapılandırılmalıdır.
Percona XtraDB Cluster ve MariaDB Galera altyapısı
Çok birincilli yazma gerektiren ortamlarda sertifikasyon tabanlı replikasyon mimarileri öne çıkar.
Percona XtraDB Cluster ile MariaDB Galera mimarilerinin temelinde sertifikasyon odaklı replikasyon modeli yer alır. Bu yaklaşımda işlem önce yerel düğümde yürütülür, ardından yazma kümesi tüm düğümlere gönderilerek sertifikasyondan geçer ve onaylanır. Neredeyse senkron (virtually synchronous) tanımı, istemciye işlem onayı dönmeden önce tüm düğümlerin veriyi fiziksel olarak işlediği anlamına gelmez.
Bütün düğümlerin yazma kabul etmesi, her uygulama iş yükünün yatayda kolayca ölçekleneceği anlamına gelmez. Aynı veri satırlarına farklı düğümlerden eşzamanlı yazılması durumunda sertifikasyon çakışmaları artar ve sistemde geri dönüş senaryoları devreye girer. Bu gibi senaryolarda uygulamanın yeniden deneme mekanizmasına sahip olması beklenir. Ekiplerin çoğu, çok birincilli yeteneğe rağmen operasyonel kararlılığı korumak için yazma trafiğini tek bir ana düğüme yönlendirmeyi tercih eder.
İki çözüm arasındaki tercih belirlenirken sürüm yaşam döngüsü, durum aktarım yöntemleri ve destek gereksinimleri göz önünde bulundurulmalıdır. Percona araç seti ve tam MySQL uyumu ön planda olduğunda PXC altyapısı, MariaDB özellikleri ile MaxScale ekosistemi tercih edildiğinde ise MariaDB Galera mimarisi daha uygundur.
PostgreSQL ve Patroni mimarisi
PostgreSQL altyapılarında dağıtık konsensüs katmanıyla lider seçimi ve otomatik yük devretme süreçleri güvenle yürütülebilir.
Patroni, PostgreSQL’in yerleşik akış replikasyonu üzerinde görev yapan bir yüksek erişilebilirlik orkestrasyon katmanıdır. etcd veya Consul gibi bir dağıtık yapılandırma deposu (DCS) üzerinden süreli lider kilidi alarak çalışır. Konsensüs mekanizmasını Patroni’nin kendisi değil, doğrudan arkasındaki DCS altyapısı sağlar.
Patroni arıza anında yük devretme kararını üretirken, istemci bağlantılarının yönlendirilmesi için HAProxy veya Envoy gibi yük dengeleyiciler devreye alınır. Bu yük dengeleyiciler sağlık kontrollerini Patroni’nin REST API uç noktası üzerinden gerçekleştirir. Bağlantı havuzu amacıyla kullanılan PgBouncer bileşeni ise tek başına bir yük devretme aracı olarak değerlendirilmemelidir.
Patroni’nin senkron mod yetenekleriyle otomatik yük devretmelerde veri kaybı riski en aza indirilir. synchronous_mode_strict seçeneği tercih edildiğinde, sağlıklı senkron yedek bulunmuyorsa yazma işlemleri durdurularak veri dayanıklılığı hizmet sürekliliğinin önüne konur. Olası bölünmüş beyin senaryolarına karşı ise lider kilidinin yanı sıra işletim sistemi seviyesinde gözetleme mekanizmaları (watchdog) ve altyapı düzeyinde düğüm izolasyonu (fencing) yöntemleriyle koruma sağlanır.
4. Çoklu yazma mimarilerinde veri tutarlılığı ve çakışma yönetimi
Birden fazla düğüme aynı anda yazma senaryolarında veri tutarlılığı uygulama düzeyinde belirlenen stratejilerle korunur.
| Değerlendirme Kriteri | MySQL InnoDB Cluster Çok Birincilli | PXC ve MariaDB Galera | PostgreSQL Yerleşik Mantıksal Replikasyon | EDB Postgres Distributed (PGD) |
|---|---|---|---|---|
| Birden fazla düğüme yazma imkanı | Evet, tüm düğümler yazma kabul edebilir | Evet, tüm düğümler yazma kabul edebilir | Abone sunucuya yerel yazma yapılabilir, ancak bu yapı hazır bir çok birincilli çözüm sunmaz | Evet, aktif-aktif mimariyle çoklu yazmayı destekler |
| Çakışma yönetimi yaklaşımı | İşlem onayı öncesinde sertifikasyon uygulanır, çakışan işlem için geri dönüş senaryosu (rollback) işletilir | Sertifikasyon kontrolü yapılır, ilk yazan kazanır kuralı geçerlidir ve yeniden deneme ihtiyacı doğar | Kısıt çatışmaları veri uygulama sürecini durdurabilir, otomatik genel bir çözüm mekanizması bulunmaz | Gelişmiş çakışma algılama ve çözme politikaları ile yazma lideri seçenekleri sunar |
| Geniş alan ağı modeli | Ağ gecikmesine karşı yüksek hassasiyet gösterir | Ağ gecikmesine ve akış kontrolü baskısına karşı hassastır | Asenkron çalıştığı için geniş alan ağlarına daha dayanıklıdır, nihai tutarlılık ve operasyonel takip gerektirir | Coğrafi olarak dağıtık yapılar için tasarlanmıştır, varsayılan mantıksal veri akışını asenkron yürütür |
| Temel değerlendirme | MySQL ortamlarında sınırlı ve dikkatli kurgulanması gereken bir yapıdır | Aynı veri merkezindeki yüksek erişilebilirlik için uygundur, veri yerelliği iyi planlanmalıdır | Veri göçü, seçici dağıtım ve CDC projeleri için elverişlidir, eksiksiz bir çoklu yazma paketi değildir | Lisans maliyetleri, çakışma modelleri ve uygulama uyumluluğu birlikte değerlendirilmelidir |
PostgreSQL’in yerleşik mantıksal replikasyon yeteneği yayın ve abonelik mekanizması sunar. Buna karşın DDL yönetimi, sayaçların senkronizasyonu, küresel tekil anahtarlar ve otomatik çakışma çözümü gibi kritik unsurları içermediği için bu yapı hazır bir çok birincilli sistem olarak değerlendirilmemelidir. Sektörde daha önce PG-BDR adıyla bilinen EDB Postgres Distributed (PGD) çözümü, aktif-aktif topolojilerde gelişmiş çakışma yönetimi sunar. Bu çözümün yerleşik bir PostgreSQL yeteneği olmadığı, ticari bir ürün olarak lisans koşullarıyla birlikte ele alınması gerektiği unutulmamalıdır.
Çok birincilli mimarilerde temel soru kaç düğüme yazılabileceği değil, aynı iş nesnesi iki farklı lokasyonda eşzamanlı değiştiğinde hangi sonucun geçerli sayılacağıdır. Son yazanın kazanması, işlemin geri dönüp yeniden denenmesi veya verinin sahipliğinin coğrafi bölgelere paylaştırılması gibi kararlar kurumun iş kurallarına göre şekillendirilir.
5. Afet kurtarma senaryoları ve çoklu veri merkezi mimarileri
Bölgeler arası yüksek erişilebilirlik tasarımlarında ağ gecikmesi ve ayrışan işlem riskleri asenkron replikasyon modelleriyle sınırlandırılır.
Aynı veri merkezinde çalışan bir yüksek erişilebilirlik kümesini geniş alan ağı üzerinden farklı coğrafyalara yaymak genellikle yüksek işlem gecikmesine ve geniş hata alanlarına yol açar. Bu nedenle her bölgede bağımsız yerel yüksek erişilebilirlik kümeleri kurmak ve bu bölgeleri birbirine asenkron afet kurtarma köprüleriyle bağlamak daha sağlıklı bir mimari yaklaşımdır.
Afet kurtarma modellerinin veri kaybı toleransına göre karşılaştırılması
Coğrafi yedeklilik sağlayan mimariler kurtarma noktası ve geçiş güvenliği kriterleriyle yapılandırılır.
| Değerlendirme Kriteri | MySQL InnoDB ClusterSet | PostgreSQL Patroni Standby Cluster | PostgreSQL Mantıksal Afet Kurtarma | Galera ve Asenkron Afet Kurtarma |
|---|---|---|---|---|
| Topoloji yapısı | Bir yazma ve okuma birincil kümesi ile bir veya daha çok salt okunur ikincil küme | Uzak kaynaktan replike olan bir yedek lider ve ona bağlı basamaklı ikincil sunucular | Yayından seçili verileri alan bağımsız abone sunucu yapısı | Yerel Galera kümesinden uzaktaki bağımsız hedefe klasik asenkron replikasyon |
| Bölgeler arası veri bağlantısı | Yalnızca asenkron bağlantı kullanılır, yarı senkron yöntem desteklenmez | Genellikle asenkron fiziksel WAL akışı tercih edilir | Genellikle asenkron mantıksal değişiklik akışı işletilir | Asenkron ikili günlük akışı kullanılır |
| Replikasyon kapsamı | Kümenin tamamını kapsar | PostgreSQL kümesinin tamamını kapsar | Seçili veri tabanı, tablo, satır veya sütunları kapsar | Yapılandırılan replikasyon kapsamını içerir |
| RPO beklentisi | Replikasyon gecikmesi kadar veri kaybı riski oluşabilir | Replikasyon gecikmesi kadar veri kaybı riski oluşabilir | Veri uygulama gecikmesine ve yuva durumuna bağlı olarak değişir | Replikasyon gecikmesi kadar veri kaybı riski oluşabilir |
| Planlı geçiş kolaylığı | MySQL Shell aracılığıyla hedef küme eşitlenerek kontrollü geçiş sağlanır | Otomasyon adımlarıyla yedek küme birincil çalışma moduna alınır | Abonelik, sayaç ve bağlantı rollerinin önceden hazırlanmasını gerektirir | Harici orkestrasyon ve işletim prosedürleri gerektirir |
| Afet anında yük devretme | Bilinçli bir yönetici kararıyla başlatılır, otomatik işletilmez | Bölgeler arasında otomatik tetiklenmez, bağımsız DCS alanları üzerinden manuel terfi planlanır | Tek komutla çalışan otomatik bir geçiş mekanizması bulunmaz | Yönetici kararı, terfi adımları ve düğüm izolasyonu gerektirir |
| Karşılaşılabilecek başlıca riskler | Eski birincil küme izole edilmeden zorunlu geçiş yapılırsa iki taraflı yazma ve ayrışan işlem kimlikleri oluşabilir | Eski birincil sunucunun yeniden erişime açılması durumunda zaman çizgisi çatışmaları doğabilir | Şema uyumsuzlukları, kısıt çatışmaları ve biriken yuvalar nedeniyle disk dolma riski barındırır | Filtre uyumsuzlukları, yanlış ana sunucu seçimi ve bölünmüş beyin sendromu görülebilir |
MySQL InnoDB ClusterSet mimarisinde temel prensip, kümeler arası iletişimde sürekliliği tutarlılığa önceleyen asenkron modelin kullanılmasıdır. Hedef kümenin geriden gelme ihtimali nedeniyle acil yük devretme süreci otomatik başlatılmaz. Eski birincil küme yeniden erişilebilir duruma geldiğinde öncelikle bu kümenin izole edilmesi sağlanmalı ve ayrışan işlemler dikkatle uzlaştırılmalıdır.
PostgreSQL Patroni Standby Cluster yapısında ise uzak lokasyonda bir yedek lider belirlenir. Bu yedek lider, ana kümeden aldığı WAL kayıtlarını yerel ikincil sunuculara dağıtır. Ana küme ile yedek kümenin aynı DCS etki alanını paylaşmaması gerekir. Yedek bölgenin kendi içindeki lider değişimleri otomatik gerçekleşirken, tüm lokasyonun ana yazma merkezine dönüştürülmesi ve eski merkezin izole edilmesi süreci kontrollü bir afet tatbikatı adımı olarak yürütülür.
6. Farklı iş senaryolarına uygun mimari tercihler
İş yükünün niteliği, bütçe ve bakım yetenekleri en uygun veri tabanı mimarisinin belirlenmesinde temel kriterlerdir.
| Kurumsal İhtiyaç | Önerilen Mimari | Tercih Nedeni ve Dikkat Noktası |
|---|---|---|
| Basit okuma ölçekleme veya düşük maliyetli afet kurtarma | MySQL Asenkron veya PostgreSQL Fiziksel Asenkron Replikasyon | İşlem onay gecikmesini en aza indirir, veri kaybı toleransı replikasyon gecikmesine bağlıdır ve otomatik yük devretme için ek orkestrasyon gerektirir |
| Aynı veri merkezinde minimum veri kaybı | MySQL Yarı Senkron veya PostgreSQL Fiziksel Senkron ile Patroni | Ağ gidiş dönüş gecikmesini dengelerken güncel yedek sunucu seçimini güvenceye alır |
| MySQL için üreticinin kendi bütünleşik yüksek erişilebilirlik çözümü | MySQL InnoDB Cluster | Group Replication, AdminAPI ve Router bileşenlerini tek bir çatı altında uyumla çalıştırır |
| MySQL ve MariaDB uyumlu çok birincilli mimari | Percona XtraDB Cluster veya MariaDB Galera | Eşzamanlı yazma gereksinimlerini karşılarken yeniden deneme, akış kontrolü ve durum aktarım süreçlerinin test edilmesini zorunlu kılar |
| PostgreSQL için kararlı tek birincilli yüksek erişilebilirlik | PostgreSQL, Patroni, DCS ve Vekil Sunucu Mimarisi | Sektörde kabul görmüş esnek bir yapı sunarken bileşenlerin bağımsız olarak yönetilmesine imkan tanır |
| Seçici veri dağıtımı veya ana sürüm yükseltme | PostgreSQL Mantıksal Replikasyon | Şema, sayaç ve yuva yönetimini içeren kapsamlı geçiş prosedürleriyle kesintisiz veri göçü sağlar |
| Çok bölgeli aktif-aktif PostgreSQL gereksinimi | EDB Postgres Distributed veya Uygulama Düzeyinde Bölümleme | Çakışma yönetimi politikalarını mimarinin merkezine yerleştirerek coğrafi süreklilik sağlar |
| Konteyner ve Kubernetes ortamlarında yüksek erişilebilirlik | CloudNativePG veya Percona Veri Tabanı Operatörleri | Dağıtım ve yaşam döngüsünü otomatikleştirirken temel replikasyon kurallarını eksiksiz uygular |
PostgreSQL ekosisteminde Patroni çözümüne alternatif olarak repmgr veya pg_auto_failover gibi araçlar ve çeşitli Kubernetes operatörleri de değerlendirilebilir. Bu araçlar arasında seçim yaparken yalnızca otomatik yük devretme yeteneğine odaklanılmamalıdır. Düğüm izolasyonu (fencing), topoloji yönetimi, yedekleme entegrasyonu, sürüm yükseltme kolaylığı ve ekibin operasyonel yetkinliği bir bütün olarak ele alınmalıdır.
7. Yüksek erişilebilirlik mimarilerinde uygulanması gereken test senaryoları
Teorik ürün vaatlerine güvenmek yerine üretim iş yükünü yansıtan simülasyonlarla sistem davranışlarını ölçümlemek gerekir.
Mimari tercihleri doğrulamak amacıyla aşağıdaki test senaryoları uygulanmalıdır:
| Test Senaryosu | Ölçülen Kritik Sonuç |
|---|---|
| Birincil sunucu sürecini sonlandırma | Arıza algılama, yedek sunucunun terfisi ve uygulamanın yeniden bağlanması dahil gerçek kurtarma süresi (RTO) |
| Birincil sunucuyu ağdan izole etme | Çoğunluk kararı, düğüm izolasyonu ve bölünmüş beyin sendromunun engellenmesi |
| İkincil sunucu ağını yavaşlatma | İşlem gecikmesi dağılımı (p95 ve p99), replikasyon gecikmesi ve günlük birikimi |
| Senkron onay düğümünü devre dışı bırakma | Yazma işlemlerinin duraklaması, asenkron moda geçiş ve yeni senkron aday belirleme süreci |
| Büyük hacimli işlem ve şema değişikliği | Sertifikasyon süresi, veri işleme gecikmesi, kilitlenme ve yeniden deneme etkileri |
| Eski birincil sunucuyu sisteme dahil etme | Kümeye yeniden katılma, zaman çizgisini geri sarma ve ayrışan işlemlerin yönetimi |
| Coğrafi afet kurtarma tatbikatı | Gerçek veri kaybı (RPO), alan adı ve vekil sunucu yönlendirmeleri ile geri dönüş senaryosu (rollback) başarımı |
Test süreçlerinde işlem gecikmesi dağılımları (p95 ve p99), replikasyon gecikmesinin bayt ve zaman karşılığı, veri işleme hızı, hata ve yeniden deneme oranları, yük devretme süreleri ve olası veri kayıpları titizlikle kayıt altına alınmalıdır.
Değerlendirme ve mimari seçim ilkeleri
Doğru yüksek erişilebilirlik mimarisi, düzenli test edilen yedekleme ve kurtarma süreçleriyle birleştiğinde gerçek iş sürekliliği sağlar.
MySQL ve PostgreSQL ekosistemlerini doğrudan bire bir özellik listeleriyle karşılaştırmak yerine katman bazlı bir yaklaşımla ele almak gerekir. Replikasyon düzeyinde MySQL asenkron veya yarı senkron modelleri ile PostgreSQL fiziksel akış replikasyonu değerlendirilirken, yüksek erişilebilirlik katmanında MySQL InnoDB Cluster ile PostgreSQL Patroni mimarileri karşılaştırılmalıdır. Afet kurtarma tarafında MySQL InnoDB ClusterSet ile Patroni Standby Cluster yapıları öne çıkar. PXC ve MariaDB Galera gibi çok birincilli modeller ise PostgreSQL yerleşik mantıksal replikasyonuyla değil, gelişmiş çakışma yönetimi sunan PGD benzeri kurumsal çözümlerle kıyaslanmalıdır.
Mimari tasarım sürecinde öncelikle hedeflenen kurtarma noktası (RPO), hedeflenen kurtarma süresi (RTO) ve kabul edilebilir işlem gecikmesi sınırları netleştirilmelidir. Ardından sistemin tek merkezden mi yoksa çoklu yazarlarla mı çalışacağı belirlenmelidir. Nihai aşamada replikasyon altyapısı, orkestrasyon araçları, trafik yönlendirme, düğüm izolasyonu ve yedekleme bileşenleri birbirini tamamlayan bir bütün olarak tasarlanmalıdır. Replikasyon mekanizmaları kullanıcı hatalarını ve mantıksal bozulmaları tüm kopyalara hızla taşıyabildiği için, yüksek erişilebilirlik ve afet kurtarma mimarileri düzenli olarak geri yükleme (restore) testleri gerçekleştirilen yedekleme stratejileriyle desteklenmelidir.
Kaynaklar
- MySQL 8.4 — Replication Implementation
- MySQL 8.4 — Semisynchronous Replication
- MySQL 8.4 — Group Replication
- MySQL 8.4 — Group Replication Fault Tolerance
- MySQL Shell 8.4 — InnoDB Cluster
- MySQL Shell 8.4 — InnoDB ClusterSet Limitations
- MySQL Shell 8.4 — Fencing Clusters
- PostgreSQL 18 — Log-Shipping Standby Servers
- PostgreSQL 18 — Logical Replication
- PostgreSQL 18 — Logical Replication Failover
- PostgreSQL 18 — Logical Replication Restrictions
- Patroni — Replication Modes
- Patroni — Standby Cluster
- Patroni — Watchdog Support
- Patroni — REST API
- Percona XtraDB Cluster — Certification
- MariaDB — Galera Cluster Overview
- EDB Postgres Distributed — Architecture