Database Engineering

Dayanıklılığı Mimari Olarak Tasarlamak: Veritabanı Eşlemesi Kurulumu İçin Pratik Bir Rehber

Modern yazılım mühendisliğinde veri sadece bir varlık değil; güven ve sürekliliğin omurgasıdır. Uygulamalar ölçeklendikçe, yüksek erişilebilirlik (HA) ve hata toleransı talepleri vazgeçilmez hale gelir. Veritabanı altyapısındaki tek nokta hataları, felaket düzeyinde kesintilere, veri kaybına ve ciddi itibar zararlarına yol açabilir. Bu risklere karşı en etkili savunma mekanizması veritabanı eşlemesidir (replication). Bu makale, sağlam bir eşleme ortamı kurmak için gereken mimari desenleri, yapılandırma stratejilerini ve pratik uygulama detaylarını incelemektedir.

Eşleme Topolojilerini Anlamak

Yapılandırma dosyalarına dalmadan önce, tutarlılık ve gecikme (latency) gereksinimlerinize göre uygun eşleme topolojisini seçmeliyiz. En yaygın iki desen, Master-Slave (Senkron/Asenkron) ve Master-Master (Çoklu Master) şeklindedir.

Master-Slave Eşlemesi, okuma ölçeklendirmesi ve felaket kurtarma için endüstri standardıdır. Birincil düğüm (Master) tüm yazma işlemlerini ve ikili günlük (binary log) güncellemelerini yönetirken, ikincil düğümler (Slaves) bu değişiklikleri asenkron olarak uygular. Bu kurulum, Master arızalandığında bir Slave'in terfi ettirilerek veri bütünlüğünün minimal çabayla korunmasını sağlar. Ancak, tüm yazıların tek bir düğümden geçmesi gerektiğinden yazma darboğazları oluşturur.

Master-Master Eşlemesi, birden fazla düğümde yazma işlemlerine izin vererek daha iyi yazma ölçeklenebilirliği ve coğrafi dağıtım sunar. Ancak, çakışma çözümü konusunda karmaşıklık ve düğümler arasında artan ağ gecikmesi getirir. Çoğu standart kurumsal uygulama için, sadeliği ve güvenilirliği nedeniyle Master-Slave, başlangıç noktası olarak önerilmeye devam etmektedir.

Yapılandırma Stratejileri: Mantıksal vs. Fiziksel

Eşleme mekanizmaları veritabanı motoruna göre değişir. PostgreSQL'de eşleme öncelikle fizikseldir ve İlerleme Öncesi Günlüğe Kaydetme (Write-Ahead Log - WAL) mekanizmasına dayanır. MySQL'de ise İfade Tabanlı Eşleme (SBR), Satır Tabanlı Eşleme (RBR) veya Karışık Mod arasında seçim yapabilirsiniz. Modern dağıtık sistemler için, daha yüksek veri tutarlılığı ve karmaşık güncelleme senaryolarında daha iyi performans sunduğu için genellikle Satır Tabanlı Eşleme tercih edilir.

Ortamınızı yapılandırırken, birincil ve replika düğümleri arasındaki ağ gecikmesini minimize ettiğinizden emin olun. Yüksek gecikme, eşleme gecikmesine yol açabilir; bu durum da "yazdığını oku" (read-your-writes) tutarlılığını ve felaket kurtarma süresini doğrudan etkiler.

Pratik Uygulama: Okuma Replikalarının Kurulması

Satır Tabanlı Eşleme ile MySQL kullanarak somut bir örneğe bakalım. Bu kurulum, raporlama sorgularını yükten arındırmak ve birincil örnekteki yükü azaltmak için idealdir.

# Primary Sunucuda my.cnf
[mysqld]
server-id = 1
log-bin = mysql-bin
binlog-format = ROW
expire_logs_days = 10
max_binlog_size = 100M

# Eşleme kullanıcısı oluşturma
CREATE USER 'repl_user'@'%' IDENTIFIED BY 'strong_password';
GRANT REPLICATION SLAVE ON *.* TO 'repl_user'@'%';
FLUSH PRIVILEGES;

Replika sunucusunda, çakışmaları önlemek amacıyla server-id açısından yapılandırmanın önemli ölçüde farklı olması gerekir.

# Replica Sunucuda my.cnf
[mysqld]
server-id = 2
log-bin = mysql-bin
read-only = 1  # Replikaya yanlışlıkla yazmayı önle
relay-log = relay-bin

Yapılandırmalar yerleştirildikten sonra, birincil sunucudan ikili günlük koordinatlarını alıp replikaya uygulamanız gerekir. Bu adım, replikanın işlem günlüğünde doğru noktadan başlamasını sağlamak için kritiktir.

-- Birincil üzerinde durumu almak için çalıştır
SHOW MASTER STATUS;

-- Replika üzerinde bağlanmak için çalıştır
CHANGE MASTER TO
  MASTER_HOST='primary_db_ip',
  MASTER_USER='repl_user',
  MASTER_PASSWORD='strong_password',
  MASTER_LOG_FILE='mysql-bin.000001',
  MASTER_LOG_POS=154;

Son olarak, eşleme işlemini başlatın ve kanalın sağlığını izleyin.

START SLAVE;
SHOW SLAVE STATUS\G

SHOW SLAVE STATUS içinde izlenmesi gereken temel alanlar arasında Seconds_Behind_Master yer alır. Bu değerde tutarlı bir artış, eşleme gecikmesini gösterir; bu durum donanım yükseltmeleri veya sorgu optimizasyonu gerektirebilir.

İzleme ve Bakım

Eşlemeyi kurmak savaşın sadece yarısıdır; bakımı titiz bir izleme gerektirir. Eşleme gecikmesi, başarısız bağlantılar ve ikili günlüklerdeki disk alanı tüketimi için otomatik uyarılar uygulayın. Prometheus ile mysqld_exporter veya özel veritabanı gözlemlenebilirlik platformları, eşleme sağlığı hakkında gerçek zamanlı içgörüler sağlayabilir.

Ayrıca, düzenli felaket kurtarma (failover) tatbikatları esastır. Ekibinizin, felaket düzeyinde bir birincil arızası durumunda bir Slave'i Master olarak terfi ettirmek için dokümante edilmiş ve test edilmiş bir çalışma kılavuzuna (runbook) sahip olduğundan emin olun. Bu hazırlık, potansiyel bir krizi yönetilebilir bir olaya dönüştürür.

Sonuç

Veritabanı eşlemesi, dayanıklı sistem tasarımının temel bir direğidir. Topolojiler arasındaki ödünleşimleri anlayarak ve eşleme kanallarınızı dikkatlice yapılandırarak, şiddetli stres altında bile mevcut kalan sistemler inşa edebilirsiniz. Okuma ağırlıklı iş yükleri için ölçeklendirme yapıyor olun veya felaket kurtarmayı sağlıyor olun; eşlemeyi ustalaşmak, her veritabanı mühendisi için vazgeçilmez bir beceridir.

Share: