MySQL ve PostgreSQL Replikasyon Kurulumu ile VPS Üzerinde Yüksek Erişilebilirlik

MySQL ve PostgreSQL Replikasyonunu VPS Üzerinde Neden Ciddiye Almalısınız?

Veritabanı tarafında gerçek anlamda yüksek erişilebilirlik (HA) hedeflediğiniz anda, tek bir VPS veya tek bir fiziksel sunucunun sınırlarına takılırsınız. İster WooCommerce tabanlı bir e-ticaret sitesi, ister SaaS ürünü, ister kurumsal CRM olsun; MySQL veya PostgreSQL veritabanınız birkaç dakika bile erişilemez olduğunda, doğrudan gelir, itibar ve operasyon kaybı yaşanır. Çoğu ekip proje planlama veya kapasite analizi toplantılarında önce CPU ve RAM hesaplar, veritabanı tarafındaki replikasyon, otomatik failover ve felaket senaryolarını ise “sonra bakarız” klasörüne koyar. Asıl sorun da burada başlar.

Bu rehberde, VPS üzerinde MySQL ve PostgreSQL replikasyon kurulumu, yüksek erişilebilirlik mimarisi ve otomatik failover mekanizmalarını adım adım ele alacağız. Amaç; teorik bir akademik tartışma değil, üretim ortamında uygulanabilir, test edilebilir ve bakımını gerçekten yapabileceğiniz bir mimari ortaya koymak. Yedeklemenin replikasyonu, replikasyonun da HA’yı tek başına çözmediğini netleştirip; hangi bileşenin ne işe yaradığını, hangi noktada işin DNS, load balancer ve uygulama katmanına taştığını pratik örneklerle konuşacağız. DCHost altyapısında VPS, dedicated veya colocation senaryolarında kullanabileceğiniz somut yapı taşlarını bir araya getirelim.

Temel Kavramlar: Yedek, Replikasyon, HA ve Otomatik Failover

Replikasyon kurulumuna girmeden önce, sık karıştırılan birkaç kavramı netleştirmek gerekiyor. Özellikle yönetim tarafıyla konuşurken terimleri doğru kullandığınızda, bütçe ve tasarım kararlarını savunmak çok daha kolaylaşır.

Yedek (Backup) vs Replikasyon

Yedek, belirli bir andaki verinizin kopyasıdır. Amaç; veri kaybı veya hatalı silme durumunda, geçmişe geri dönebilmektir. Genellikle RPO/RTO hedeflerine uygun şekilde, saatlik/günlük/haftalık olarak alınır.

Replikasyon ise veritabanındaki değişikliklerin başka bir sunucuya anlık veya anlığa yakın olarak aktarılmasıdır. Amacı:

• Okuma yükünü dağıtmak (read scaling)
• Bir veritabanı sunucusu arızalandığında, diğerini devreye almak (HA/failover)
• Bazen de bölgesel felaket dayanıklılığı sağlamak (DR/geo-replikasyon)

Yani yedekler geçmişe dönüş içindir, replikasyon ise anlık süreklilik için. Bu konuyu daha derinlemesine ele aldığımız uygulama-tutarlı MySQL/PostgreSQL yedekleri almak rehberini mutlaka bu yazıyla birlikte düşünün.

Yüksek Erişilebilirlik (HA) ve Failover

Yüksek erişilebilirlik, sisteminizin planlanmamış kesintilere rağmen belirli bir yüzdede (ör. %99.9) çalışır kalması hedefidir. Bu hedefe ulaşmak için genellikle şu bileşenler birlikte tasarlanır:

• Veritabanı replikasyonu (MySQL / PostgreSQL)
• Otomatik lider seçimi ve failover mekanizması
• Uygulama ile veritabanı arasına koyulan akıllı bir katman (proxy, load balancer veya DNS)
• İzleme, alarm ve manuel müdahale için net bir runbook

Bu kavramları daha üst düzeyde ele aldığımız Yüksek kullanılabilirlik (HA) nedir yazısı, stratejik çerçeveyi kurmanıza yardımcı olacaktır. Burada ise doğrudan MySQL ve PostgreSQL üzerinde teknik uygulamaya odaklanacağız.

Senkronsuz vs Senkron Replikasyon

Hem MySQL hem de PostgreSQL tarafında iki temel yaklaşım vardır:

• Asenkron (senkronsuz) replikasyon: Primary yazdığı anda başarılı sayar, replica daha sonra yakalar. Avantajı hızlıdır; dezavantajı failover sırasında çok küçük de olsa veri kaybı (RPO > 0) ihtimalidir.
• Senkron replikasyon: Primary, en az bir replica yazmayı onaylamadan işlemi başarılı saymaz. Avantajı teorik olarak sıfıra yakın veri kaybı; dezavantajı ise gecikme ve performans maliyetidir.

VPS ortamlarında çoğu senaryoda asenkron veya yarı-senkron yapı tercih edilir; çünkü ağ gecikmesi, disk I/O ve CPU maliyetleri, tam senkron yapıları her zaman ekonomik kılmaz.

VPS Üzerinde Örnek HA Mimarisi: 2+1 Yaklaşımı

DCHost altyapısında sık kullandığımız basit ama iş gören şablon, şu 2+1 mimarisidir:

• VPS1: Primary veritabanı (MySQL veya PostgreSQL)
• VPS2: Replica veritabanı (read-only, failover adayı)
• VPS3: Witness / koordinatör (HA aracı, etcd/Consul, Orchestrator, Patroni veya sadece izleme ve otomasyon script’leri)

İki veritabanı sunucusu arasında bir sorun çıktığında, üçüncü node devreye girip çoğunluğu sağlayan tarafı belirler ve split-brain (iki tarafın da kendini lider sanması) riskini azaltır. Mümkünse VPS’lerinizin aynı veri merkezinde ama farklı fiziksel host’larda konumlanmasını, disk tarafında NVMe depolama kullanılmasını ve özel bir iç ağ üzerinden konuşmasını öneriyoruz.

Eğer coğrafi yedeklilik düşünüyorsanız, bu şablonu farklı bölgelerdeki veritabanı cluster’larıyla birleştirip, çok bölgeli veritabanı mimarileri yazımızdaki DNS ve geo-routing stratejileriyle zenginleştirebilirsiniz.

MySQL Üzerinde Primary–Replica Replikasyon Kurulumu

Önce MySQL tarafında klasik primary–replica replikasyon kurulumu ile başlayalım. Örnekte iki VPS kullanacağız:

• VPS1 (primary): 10.0.0.1
• VPS2 (replica): 10.0.0.2

İşletim sistemi olarak Debian/Ubuntu veya RHEL türevlerinden birini kullanabilirsiniz; mantık aynıdır.

1. MySQL Kurulumu ve Temel Güvenlik

Her iki VPS’te de MySQL sunucusunu kurduğunuzu ve root şifresini belirlediğinizi varsayalım. Ek olarak:

• İstemcilerin yalnızca uygulama sunucularından ve replikasyon sunucularından bağlanmasına izin verin.
• MySQL portunu (varsayılan 3306) dış dünyaya açmayın; güvenlik duvarı veya iç ağ kullanın.

2. Primary (VPS1) Üzerinde Replikasyon Ayarları

Primary sunucunun my.cnf (veya mysqld.cnf) dosyasında temel ayarları yapın:

[mysqld]
server-id = 1
log_bin = mysql-bin
binlog_format = ROW
relay_log = relay-bin

MySQL’i yeniden başlatın ve replikasyon kullanıcısını oluşturun:

CREATE USER 'repl'@'10.0.0.%' IDENTIFIED BY 'GüçlüBirParola';
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'10.0.0.%';
FLUSH PRIVILEGES;

Sonrasında, replikayı başlatmak için bir referans noktası elde etmemiz gerekiyor:

FLUSH TABLES WITH READ LOCK;
SHOW MASTER STATUS;

Bu komutun çıktısındaki File ve Position değerlerini bir yere not edin. Tablo kilidi açıkken bir tam yedek almanız idealdir; bu aynı zamanda replikayı başlatmak için temiz bir kopya sağlar:

mysqldump --all-databases --single-transaction --master-data=2 
  --routines --triggers --events > /root/full.sql
UNLOCK TABLES;

3. Replica (VPS2) Üzerinde İlk Senkronizasyon

Replica tarafında my.cnf ayarlarını yapın:

[mysqld]
server-id = 2
relay_log = relay-bin
read_only = 1

Veritabanını temizleyip primary’den aldığınız yedeği içeri aktarın:

mysql < /root/full.sql

Ardından replikasyonu başlatın. Primary’den aldığınız SHOW MASTER STATUS çıktısını kullanarak:

CHANGE REPLICATION SOURCE TO
  SOURCE_HOST = '10.0.0.1',
  SOURCE_USER = 'repl',
  SOURCE_PASSWORD = 'GüçlüBirParola',
  SOURCE_LOG_FILE = 'mysql-bin.000001',
  SOURCE_LOG_POS = 123456;

START REPLICA;

Durumu kontrol etmek için:

SHOW REPLICA STATUSG

Replica_IO_Running ve Replica_SQL_Running alanlarının Yes olması gerekir.

4. Otomatik Failover için Basit Yaklaşım

MySQL tarafında otomatik failover için birkaç farklı araç ve yaklaşım var: MHA, Orchestrator, MySQL Router, ProxySQL gibi. DCHost tarafında küçük ve orta ölçekli projelerde sık kullandığımız, nispeten sade bir yaklaşım şu bileşenleri içeriyor:

• VPS3 üzerinde çalışan bir Orchestrator veya benzeri HA aracı
• Uygulamanın veritabanına doğrudan IP ile değil, bir sanallaştırılmış IP (VIP) veya proxy üzerinden bağlanması
• Failover sonrasında DNS veya VIP güncellemesini otomatik yapan kısa script’ler

Daha ileri seviye senaryolarda Group Replication veya Galera Cluster gibi çözümlerle tam HA cluster kurmak da mümkün; bunu MySQL için gelişmiş HA çözümleri yazımızda ayrı ayrı ele aldık. Bu makalede odak noktamız, temel primary–replica yapısını sahaya indirebilmek.

PostgreSQL Streaming Replikasyon ve Patroni ile HA

PostgreSQL tarafında replikasyon ve otomatik failover için ekosistem biraz daha olgun ve bütünsel. En bilinen yaklaşımlardan biri, streaming replication + Patroni kombinasyonu. Yine iki veritabanı VPS’i ve bir koordinatör VPS’i kullanan bir senaryoya bakalım.

1. Temel PostgreSQL Kurulumu ve Ayarlar

PostgreSQL’i her iki VPS’e de kurduğunuzu ve veritabanınızın Primary olarak VPS1’de çalıştığını varsayalım. Önce primary üzerinde gerekli ayarları yapıyoruz.

postgresql.conf üzerinde:

wal_level = replica
max_wal_senders = 10
max_replication_slots = 10
archive_mode = on
archive_command = 'test ! -f /var/lib/postgresql/wal/%f && cp %p /var/lib/postgresql/wal/%f'

pg_hba.conf içinde replikasyon yetkisi vereceğiniz replica IP’sini ekleyin:

host replication repl 10.0.0.2/32 md5

Ardından bir replikasyon kullanıcısı oluşturun:

CREATE ROLE repl WITH REPLICATION LOGIN PASSWORD 'GüçlüBirParola';

2. Replica İçin Base Backup Alma

Replica sunucusunda PostgreSQL servisini durdurun ve data dizinini temizleyin. Ardından primary üzerinden pg_basebackup ile tam kopya alın:

pg_basebackup -h 10.0.0.1 -D /var/lib/postgresql/data 
  -U repl -P -R --slot=replica1

-R parametresi, gerekli standby.signal ve bağlantı ayarlarını otomatik oluşturur. PostgreSQL’i replica tarafında yeniden başlattığınızda, streaming replication çalışmaya başlayacaktır.

3. Patroni ile Otomatik Failover Mantığı

Patroni, PostgreSQL cluster’larında lider seçimi ve otomatik failover’ı yöneten, saha tecrübesi yüksek bir araç. Tipik kurulumda:

• Her PostgreSQL VPS’inde bir Patroni instance’ı çalışır.
• VPS3 üzerinde etcd veya Consul gibi bir dağıtık anahtar-değer deposu bulunur.
• Patroni, bu KV deposu üzerinden cluster durumunu takip eder ve lider seçimi yapar.
• Uygulama, doğrudan veritabanına değil; HAProxy / pgbouncer gibi bir ara katmana bağlanır.

Yapı kabaca şu şekilde görünür:

• VPS1: PostgreSQL + Patroni (primary adayı)
• VPS2: PostgreSQL + Patroni (replica, failover adayı)
• VPS3: etcd/Consul + HAProxy (trafik yönlendirici)

Patroni, primary node’un sağlık kontrolleri başarısız olduğunda, çoğunluk sağlanıyorsa replica’yı yeni primary yapar. HAProxy de bağlantıları otomatik olarak yeni primary node’a yönlendirir.

4. Örnek Patroni Yapılandırma İskeleti

Detaylı ayarlar kurulum ve dağıtımınıza göre değişecektir; ancak Patroni yapılandırma dosyasının iskeleti genelde şu alanları içerir:

scope: mycluster
namespace: /db/
name: pg1

restapi:
  listen: 0.0.0.0:8008
  connect_address: 10.0.0.1:8008

etcd:
  host: 10.0.0.3:2379

postgresql:
  listen: 0.0.0.0:5432
  connect_address: 10.0.0.1:5432
  data_dir: /var/lib/postgresql/data
  bin_dir: /usr/lib/postgresql/15/bin
  authentication:
    superuser:
      username: postgres
      password: SuperGizli
    replication:
      username: repl
      password: GüçlüBirParola

İkinci node’da (pg2) sadece name ve connect_address alanlarını kendi IP’sine göre değiştirirsiniz. etcd/Consul tarafında ise çok basit bir cluster konfigürasyonu yeterli olur.

Performans tarafında, WAL ayarları ve bellek parametreleri de kritik. PostgreSQL’i replikasyonlu bir yapıda uçurmak için VPS üzerinde PostgreSQL performans ayarları rehberindeki shared_buffers, work_mem ve WAL optimizasyonlarını bu mimariyle birlikte düşünmenizi öneririm.

Uygulama Katmanı: Bağlantıları Nasıl Akıllandırırsınız?

Sadece veritabanı tarafında replikasyon kurmak, uygulamanın bunu doğru kullanacağı anlamına gelmez. HA’nın gerçekten işe yaraması için, uygulamanın veritabanına bağlanma şekli de tasarımın bir parçası olmalı.

MySQL İçin Bağlantı Stratejileri

• Tek bağlantı ucu: Uygulama, örneğin db-internal.example.com gibi tek bir hostname’e bağlanır. Bu hostname ya bir VIP’ye ya da proxy’ye işaret eder.
• Proxy katmanı: ProxySQL, HAProxy veya benzeri araçlarla read/write ayrımı, health check ve failover sonrası otomatik yönlendirme yapılabilir.
• DNS tabanlı yönlendirme: Basit senaryolarda, kısa TTL’li bir DNS kaydıyla primary IP’si güncellenebilir; ancak bu yöntem client cache’leri nedeniyle tam deterministik değildir.

Orta ve büyük projelerde pratik yaklaşım, uygulamayı bir proxy katmanına bağlamak ve arka planda primary/replica değişikliklerini bu katmanda yönetmektir.

PostgreSQL İçin Bağlantı Stratejileri

PostgreSQL dünyasında pgbouncer veya HAProxy sık kullanılır. Örneğin:

• HAProxy, Patroni REST API’sini kullanarak hangi node’un primary olduğunu bilir.
• Uygulama, her zaman HAProxy IP/hostname’ine bağlanır.
• Arka planda failover gerçekleşse bile uygulama için bağlantı ucu değişmez.

Böylece uygulama kodunu veritabanı cluster’ındaki lider değişimlerinden mümkün olduğunca yalıtmış olursunuz.

İzleme, Alarm ve Runbook: HA’nın Sigortası

Replikasyon ve otomatik failover kurulumları, ilk günkü testlerinde güzel görünür. Asıl sınav, 6 ay sonra kimsenin elini sürmediği, birkaç bakım yaması görmüş, disk dolma sınırına yaklaşmış sistemlerde gelir. Bu yüzden izlemeden ve runbook’tan bağımsız bir HA mimarisi düşünmemelisiniz.

İzlenmesi Gereken Temel Metrikler

• Replikasyon gecikmesi: MySQL’de Seconds_Behind_Master, PostgreSQL’de pg_stat_replication görünümü.
• Disk kullanım oranı: WAL/binlog klasörlerinin dolma riski.
• CPU ve RAM: Özellikle checkpoint ve vacuum dönemlerinde ani sıçramalar.
• Bağlantı sayısı: Uygulama bağlantılarının sınırları zorlayıp zorlamadığı.

Bu konuyu somut örneklerle ele aldığımız VPS izleme ve uyarı kurulum rehberi, HA veritabanı mimarinizin üstüne koymanız gereken önemli bir katman.

Runbook: Arıza Anında Kim Ne Yapacak?

Otomatik failover olsa bile, bazı senaryolarda manuel onarım gerekir. Örneğin:

• Primary diski tamamen bozuldu, replica yeni primary oldu. Eski primary yeniden ayağa kalkarken forced demotion senaryosu tanımlı mı?
• Replikasyon uzun süre geride kaldı; yeniden senkronizasyon için ne kadar kesinti göze alınabilir?
• DNS veya VIP güncellemeleri başarısız olursa, uygulama tarafındaki connection string’ler nasıl ve ne hızda güncellenecek?

Bu soruların yanıtlarını önceden yazılmış bir runbook’ta netleştirmek, felaket anında “şimdi ne yapıyoruz?” paniğini ciddi şekilde azaltır. Felaket kurtarma planı ve runbook hazırlama rehberimiz, bu aşamada iyi bir tamamlayıcıdır.

Test Senaryoları: Replikasyon ve Failover Gerçekten Çalışıyor mu?

Kurulum bittiğinde, “loglarda hata yok” diye rahatlamak yeterli değil. En azından aşağıdaki testleri düzenli aralıklarla yapmanızı öneriyoruz:

1. Replikasyon Tutarlılık Testi

1. Primary üzerinde test amaçlı küçük bir tablo ve birkaç satır oluşturun.
2. Replica üzerinde sadece-okunur modda aynı tabloyu kontrol edin.
3. Belli aralıklarla, önemli tablolar için checksum karşılaştırması yapan basit script’ler yazın.

MySQL tarafında pt-table-checksum gibi araçlar, PostgreSQL tarafında ise pg_checksums ve benzeri çözümler bu iş için kullanılabilir.

2. Kontrollü Failover Testi

1. Primary node’u kontrollü şekilde durdurun (servisi stop etmek veya network’ü kesmek gibi).
2. Otomatik failover mekanizmasının yeni primary’yi atadığını ve proxy/DNS/VIP katmanının bunu takip ettiğini doğrulayın.
3. Uygulama tarafında kesinti süresini ölçün: RTO hedeflerinize uyuyor mu?

Bu testleri, trafik düşükken planlı bakım pencerelerinde tekrarlamak, teoride tasarladığınız HA mimarisinin pratikte ne kadar dayanıklı olduğunu netleştirir.

DCHost Üzerinde MySQL ve PostgreSQL HA Mimarisi Nasıl Konumlanır?

DCHost olarak sunduğumuz VPS, dedicated ve colocation çözümlerinde, veritabanı replikasyonu ve HA mimarilerini doğrudan altyapı tasarımının bir parçası olarak düşünüyoruz. Özellikle:

• NVMe diskli VPS’ler üzerinde, MySQL binlog ve PostgreSQL WAL performansını optimum seviyede tutacak IOPS kapasitesi
• Aynı veri merkezinde, farklı fiziksel host’lara dağıtılmış node’lar ile tek nokta arıza (SPOF) riskini azaltma
• İç ağ (private network) veya VPN tünelleriyle, replikasyon trafiğini izole edip güvence altına alma

Eğer MySQL tarafında Group Replication veya Galera Cluster, PostgreSQL tarafında ise Patroni + HAProxy gibi çözümleri daha ileri düzeyde kurgulamak istiyorsanız; yüksek erişilebilirlik mi güçlü tek sunucu mu yazımızdaki karar şemasını okuduktan sonra, ekibimizle birlikte sizin kullanım senaryonuza uygun bir topoloji planlayabiliriz.

Özet ve Sonraki Adımlar

MySQL ve PostgreSQL replikasyonu, tek başına sihirli bir “kesintisizlik” çözümü değil; ancak doğru kurulduğunda ve düzenli test edildiğinde, VPS üzerindeki veritabanı katmanınızı birkaç seviye yukarı taşıyan kritik bir yapı taşı. Bu yazıda, primary–replica mantığından başlayarak, Patroni ve Orchestrator gibi araçlarla otomatik failover kavramına, uygulama katmanında proxy kullanmanın önemine ve izleme-runbook ikilisinin HA’nın gerçek sigortası olduğuna kadar uzanan bir yol haritası çizdik.

Buradan sonra atabileceğiniz somut adımlar şunlar olabilir:

• Mevcut veritabanı mimarinizi çıkarıp, RPO/RTO hedeflerinizi netleştirmek
• Küçük bir ortamda (örneğin 2+1 VPS) MySQL veya PostgreSQL replikasyonunu deneysel olarak kurmak
• Yedekleme stratejinizi, replikasyon yapınızla çelişmeyecek şekilde güncellemek
• İzleme ve alarm katmanını, HA ihtiyaçlarınıza göre yeniden tasarlamak

DCHost altyapısında yeni bir proje kuruyorsanız ya da mevcut sisteminizi HA mimarisine taşımak istiyorsanız, doğru VPS boyutlandırmasından, çok bölgeli veritabanı replikasyonuna kadar tüm adımları birlikte planlayabiliriz. Tek VPS’ten çok node’lu cluster’a giden yolda, hangi noktada hangi teknolojiyi devreye almanız gerektiğini netleştirmek için bizimle iletişime geçmeniz yeterli.