Galera Cluster ile MySQL Yüksek Erişilebilirlik

Tek bir MySQL sunucusuyla çalışan her sistemin bir gün karşılaşacağı soru şudur: bu makine yeniden başlatılırken, diski dolarken ya da çekirdek güncellemesi alırken uygulama ne yapacak? Klasik master-slave replikasyon bu soruyu kısmen çözer ama yazma işlemleri hâlâ tek bir sunucuya bağımlıdır ve master düştüğünde birinin elle failover yapması gerekir. Galera Cluster ile MySQL yüksek erişilebilirlik kurgusu tam olarak bu boşluğu doldurur: üç düğümün üçü de yazma kabul eder, veri her düğümde eşzamanlı olarak tutarlıdır ve bir düğüm kaybolduğunda kalan ikisi hiçbir şey olmamış gibi devam eder.

Bu rehberde Galera'nın nasıl çalıştığını, üç sunuculu bir kümeyi sıfırdan nasıl kuracağını, ilk düğümü bootstrap ederken hangi sıraya uyman gerektiğini ve kümenin sağlığını hangi değişkenlerle izleyeceğini anlatacağım. Ayrıca üretimde en çok can yakan konulara — split-brain, SST fırtınası, safe_to_bootstrap bayrağı ve uygulama tarafındaki deadlock davranışı — ayrı bölümler ayırdım. Örnekleri MariaDB üzerinden vereceğim çünkü Galera, MariaDB'de dağıtımın parçası olarak gelir ve kurulumu en pürüzsüz yol budur.

Galera Cluster Nasıl Çalışır#

Galera, MySQL'in kendi asenkron replikasyonunun yerine geçen bir çoğaltma katmanıdır. Klasik replikasyonda master bir işlemi kendi diskine yazar, sonra binlog üzerinden slave'e gönderir; slave bunu geriden uygular. Bu yüzden slave'in ne kadar geride kaldığı belirsizdir ve master çöktüğünde henüz aktarılmamış işlemler kaybolabilir. Galera ise sanal eşzamanlı (virtually synchronous) çalışır: bir işlem COMMIT edildiğinde, değişiklik seti (write-set) tüm düğümlere gönderilir ve her düğüm bu seti kabul ettiğini onaylamadan commit başarılı sayılmaz. Yani commit döndüğünde veri kümenin tamamına ulaşmıştır.

Buradaki "sanal" kelimesi önemli. Write-set tüm düğümlere ulaşır ve sıraya alınır, ama diğer düğümlerde diske yazılması birkaç milisaniye gecikebilir. Bu tasarım tercihi sayesinde yazma gecikmesi kabul edilebilir seviyede kalır. Bunun pratik sonucu şudur: bir düğüme yazıp hemen başka bir düğümden okursan, çok küçük bir ihtimalle henüz uygulanmamış veriyi görmeyebilirsin. Bunu kapatmak istersen wsrep_sync_wait değişkeni devreye girer; oturum başına açılır ve okuma öncesi kuyruğun boşalmasını bekletir. Kümenin karar mekanizması ise quorum üzerine kuruludur: bir düğüm, kümenin yarısından fazlasıyla haberleşemiyorsa kendini hizmet dışına alır. Bu yüzden düğüm sayısı daima tek olmalıdır; üç düğüm bir düğüm kaybını, beş düğüm iki düğüm kaybını tolere eder.

Kurulum Öncesi Planlama ve Ağ Gereksinimleri#

Galera'yı kurmadan önce üç sunucunun birbirini düşük gecikmeyle görebildiğinden emin olmalısın. Aynı veri merkezinde, tercihen aynı ağ segmentinde duran makineler idealdir; şehirler arası bir kurulumda her commit ek gecikme alır ve yazma performansı gözle görülür biçimde düşer. Üç düğümü 185.12.34.51, 185.12.34.52 ve 185.12.34.53 olarak adlandıralım. Sunucu kaynaklarını planlarken kümenin bir düğümü kaybettiğinde kalan iki düğümün tüm trafiği taşıyabileceğini varsay; yani kapasiteyi tek düğüm üzerinden değil, N-1 üzerinden hesapla.

Galera dört ayrı port kullanır ve bunların üçü çoğu kurulumda unutulup saatlerce "düğüm kümeye katılmıyor" hatasına yol açar:

Bu portları yalnızca düğümlerin birbirine açman gerekir, dünyaya değil. UFW kullanıyorsan kaynak IP bazlı kural yazmak en temizidir:

# Her düğümde, diğer iki düğümün IP'si için tekrarla
sudo ufw allow from 185.12.34.52 to any port 3306,4567,4568,4444 proto tcp
sudo ufw allow from 185.12.34.52 to any port 4567 proto udp
sudo ufw allow from 185.12.34.53 to any port 3306,4567,4568,4444 proto tcp
sudo ufw allow from 185.12.34.53 to any port 4567 proto udp

SELinux veya AppArmor açıksa MariaDB'nin 4444 ve 4567 portlarına bağlanmasına izin vermen gerekebilir. Tek başına sunucu hazırlamak istemiyorsan Clou.TR'nin sunucu yönetimi hizmeti ağ ve güvenlik duvarı katmanını da kapsıyor; kendi kaynaklarını yönetmek istiyorsan üç ayrı VDS ya da bulut sunucu yeterli bir başlangıçtır.

MariaDB ve Galera Paketlerinin Kurulumu#

Ubuntu ve Debian tabanlı sistemlerde MariaDB sunucu paketi Galera sağlayıcısını da beraberinde getirir; ayrıca mariadb-backup paketini kurman gerekir çünkü SST için önerilen yöntem budur. Üç sunucunun üçünde de aynı MariaDB ana sürümünü kur; farklı sürümlerden oluşan bir küme kurulmaz.

sudo apt update
sudo apt install -y mariadb-server mariadb-client mariadb-backup rsync
# Kurulum sonrası servisi durdur; yapılandırma bitmeden başlatma
sudo systemctl stop mariadb

Şimdi her düğümde /etc/mysql/mariadb.conf.d/60-galera.cnf dosyasını oluştur. Dosyanın büyük bölümü üç sunucuda birebir aynıdır; yalnızca son iki satır düğüme özeldir.

[mysqld]
# --- Galera'nın çalışması için zorunlu temel ayarlar ---
binlog_format=ROW
default_storage_engine=InnoDB
innodb_autoinc_lock_mode=2
bind-address=0.0.0.0

# --- Galera sağlayıcısı ---
wsrep_on=ON
wsrep_provider=/usr/lib/galera/libgalera_smm.so
wsrep_cluster_name=clou_db_cluster
wsrep_cluster_address=gcomm://185.12.34.51,185.12.34.52,185.12.34.53

# --- Durum transferi (SST) ---
wsrep_sst_method=mariabackup
wsrep_sst_auth=sstuser:GucluBirParola

# --- Bu satırlar her düğümde FARKLI olacak ---
wsrep_node_address=185.12.34.51
wsrep_node_name=db1

innodb_autoinc_lock_mode=2 ve binlog_format=ROW pazarlık konusu değildir; ilki olmadan çoklu yazmada auto increment çakışır, ikincisi olmadan write-set üretilemez. wsrep_sst_method olarak mariabackup seçmenin sebebi ise şu: alternatif olan rsync, transfer boyunca veri kaynağı düğümü tamamen kilitler. Büyük bir veritabanında bu, kümenin bir düğümünün dakikalarca yazma kabul etmemesi demektir. mariabackup ise sıcak yedek mantığıyla çalışır ve kaynak düğüm hizmet vermeye devam eder — aynı mantığın tek sunucudaki karşılığını Percona XtraBackup ile sıcak yedekleme yazısında ayrıntısıyla bulabilirsin.

SST kullanıcısını ilk düğümde oluşturacaksın; küme kurulduktan sonra bu kullanıcı otomatik olarak diğer düğümlere de yayılır.

İlk Düğümü Bootstrap Etmek ve Kümeyi Büyütmek#

Galera kurulumunda en kritik an budur ve sırası yanlış yapıldığında iki ayrı küme oluşur. Boş bir kümede hiçbir düğüm "bağlanacak birini" bulamaz, bu yüzden ilk düğüm özel bir komutla, kendini kümenin başlangıcı ilan ederek açılır.

1. Yalnızca birinci düğümde kümeyi başlat:

sudo galera_new_cluster
sudo systemctl status mariadb --no-pager

2. Aynı düğümde SST kullanıcısını oluştur ve yetkilendir:

CREATE USER 'sstuser'@'localhost' IDENTIFIED BY 'GucluBirParola';
GRANT RELOAD, PROCESS, LOCK TABLES, BINLOG MONITOR ON *.* TO 'sstuser'@'localhost';
FLUSH PRIVILEGES;

3. Küme boyutunu doğrula. Tek düğüm varken sonuç 1 dönmelidir:

mysql -e "SHOW STATUS LIKE 'wsrep_cluster_size';"
# +--------------------+-------+
# | Variable_name      | Value |
# +--------------------+-------+
# | wsrep_cluster_size | 1     |
# +--------------------+-------+

4. Şimdi ikinci düğümü normal şekilde başlat. Bu düğüm gcomm:// listesindeki adreslere bağlanır, mevcut kümeyi bulur ve veriyi SST ile çeker:

sudo systemctl start mariadb
sudo journalctl -u mariadb -f    # SST ilerlemesini canlı izle

5. İkinci düğüm Synced duruma geçtikten sonra üçüncü düğümü başlat. İkisini aynı anda başlatma; iki eşzamanlı SST aynı kaynak düğümü gereksiz yere yorar.

Üçü de ayaktayken wsrep_cluster_size üç düğümde de 3 dönmelidir. Bu sayı düğümler arasında farklıysa ağ katmanında bir sorun var demektir, önce 4567 portunu kontrol et.

Kümenin Sağlığını İzlemek#

Galera durumunu neredeyse tamamen wsrep_ önekli durum değişkenleri üzerinden anlatır. Günlük kontrolde bakman gereken beş tanesi şunlardır:

SHOW STATUS WHERE Variable_name IN (
  'wsrep_cluster_size', 'wsrep_cluster_status', 'wsrep_ready',
  'wsrep_connected', 'wsrep_local_state_comment', 'wsrep_local_recv_queue_avg'
);

wsrep_cluster_status değeri non-Primary ise o düğüm quorum kaybetmiştir ve yalnızca hata döndürür; bu bir arıza değil, kasıtlı bir korumadır. wsrep_local_recv_queue_avg sürekli 1'in üzerindeyse o düğüm yavaş kalıyordur — genellikle diski diğerlerinden zayıftır ya da üzerinde ağır raporlama sorguları çalışıyordur. Bu tür yavaşlıkları yakalamak için slow query log yapılandırma yazısındaki kurulumu her düğümde açık tutmanı öneririm. Bunu bir izleme sistemine bağlamak istersen mysql -N -B -e çıktısını doğrudan bir kontrol betiğine besleyebilirsin.

Uygulama Tarafında Değişen Davranışlar#

Galera'ya geçen bir uygulamada kod tarafında iki şey mutlaka gözden geçirilmelidir. Birincisi çakışma kaynaklı geri alma (certification failure). İki farklı düğümde aynı satır aynı anda güncellenirse, Galera bunlardan birini commit anında reddeder ve uygulamaya deadlock hatası döner. Bu hata tek sunuculu MySQL'de nadiren görülürken Galera'da normal işleyişin parçasıdır. Çözüm basittir: yazma işlemlerini kısa tut ve deadlock aldığında işlemi yeniden dene.

-- Uygulama bu hatayı görürse işlemi baştan denemeli:
-- ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction

İkinci konu birincil anahtar zorunluluğudur. Galera, birincil anahtarı olmayan InnoDB tablolarında satırları güvenilir biçimde eşleştiremez; böyle bir tabloda DELETE ve UPDATE davranışı düğümler arasında farklılaşabilir. Kümeye geçmeden önce bütün tabloları tara:

SELECT t.table_schema, t.table_name
FROM information_schema.tables t
LEFT JOIN information_schema.table_constraints c
  ON c.table_schema = t.table_schema
 AND c.table_name  = t.table_name
 AND c.constraint_type = 'PRIMARY KEY'
WHERE t.table_schema NOT IN ('mysql','information_schema','performance_schema','sys')
  AND t.table_type = 'BASE TABLE'
  AND c.constraint_name IS NULL;

Bu sorgu boş dönmüyorsa, listedeki her tabloya birincil anahtar eklemeden kümeye geçme. Ayrıca MyISAM tabloları Galera tarafından güvenilir biçimde çoğaltılmaz; hepsini InnoDB'ye dönüştür. Uygulamanın yazmaları tek bir düğüme, okumaları hepsine dağıtmasını istiyorsan araya bir yönlendirme katmanı koymak en temiz çözümdür; ProxySQL ile veritabanı yük dengeleme yazısı tam olarak bu kurguyu anlatıyor.

Sık Yapılan Hatalar ve Kurtarma Senaryoları#

En sık karşılaştığım hata, tüm küme kapandıktan sonra yanlış düğümden bootstrap etmektir. Küme tamamen durduğunda her düğümün veri dizininde grastate.dat dosyası bulunur ve içinde safe_to_bootstrap bayrağı vardır. Yalnızca bu değeri 1 olan düğüm kümeyi yeniden başlatmalıdır, çünkü en güncel veriye sahip olan odur.

sudo cat /var/lib/mysql/grastate.dat
# seqno: 154872
# safe_to_bootstrap: 1

Elektrik kesintisi gibi ani kapanmalarda hiçbir düğümde bu bayrak 1 olmayabilir. Bu durumda tüm düğümlerde seqno değerine bak ve en yüksek olanı seç; o düğümde bayrağı elle 1 yapıp galera_new_cluster ile başlat, diğerlerini normal başlat. Yanlış düğümden bootstrap edersen o düğümdeki eski veri "doğru" kabul edilir ve diğerlerinin güncel verisi SST sırasında silinir — geri dönüşü olmayan bir kayıptır.

İkinci klasik tuzak iki düğümlü küme kurmaktır. İki düğümde bir tanesi düşerse kalan düğüm quorum sağlayamaz ve kendini non-Primary yapar; yani hiçbir şey kazanmış olmazsın. Üçüncü bir tam düğüm için kaynak ayıramıyorsan, veri tutmayan hafif bir hakem süreci olan garbd çalıştır:

# Üçüncü, küçük bir makinede yalnızca oy hakkı için
garbd -a gcomm://185.12.34.51:4567,185.12.34.52:4567 -g clou_db_cluster -l /var/log/garbd.log -d

Üçüncü hata SST fırtınasıdır: bir düğüm sürekli kümeden düşüp yeniden katılıyor ve her seferinde tam SST çekiyorsa, kaynak düğümün diski ve ağı boğulur. Bunun kökeni genelde gcache boyutunun küçük olmasıdır. gcache, son write-set'leri hafızada tutan halka tampondur; bir düğüm kısa süreliğine kopup döndüğünde eksik parçalar hâlâ oradaysa tam SST yerine çok daha ucuz olan IST yapılır. Yoğun yazma alan sistemlerde bunu büyütmek gerekir:

# 60-galera.cnf içinde, wsrep_provider satırının hemen altına
wsrep_provider_options="gcache.size=2G; gcs.fc_limit=64"

Son olarak, yedeği kümenin varlığıyla karıştırma. Galera bir yedekleme çözümü değildir; yanlışlıkla çalıştırılan bir DELETE ifadesi milisaniyeler içinde üç düğümde birden uygulanır. Kümenin yanında düzenli mantıksal ve fiziksel yedek almaya devam et; mysqldump ile veritabanı yedekleme küçük veri setleri için, XtraBackup ise büyükler için doğru araçtır. Sunucu dışına kopya almak istersen yedekleme hizmetimiz bu işi zamanlanmış şekilde üstlenir.

Sıkça Sorulan Sorular#

Galera Cluster kaç sunucu ile kurulmalı#

En az üç sunucu ile kurulmalıdır ve düğüm sayısı daima tek olmalıdır. Üç düğüm bir düğüm kaybını sorunsuz tolere eder; iki düğümlü bir kurulumda ise biri düştüğünde kalan düğüm quorum sağlayamaz ve hizmet vermeyi durdurur. Üçüncü bir tam sunucu için bütçen yoksa, veri tutmayan hakem süreci garbd küçük bir makinede çalıştırılarak oy sayısı tekleştirilebilir.

Galera ile klasik MySQL replikasyonu arasındaki fark nedir#

Klasik replikasyon asenkrondur: master işlemi kendi diskine yazar ve slave bunu geriden uygular, bu yüzden slave'in ne kadar geride olduğu belirsizdir. Galera ise write-set'i commit anında tüm düğümlere onaylatır, dolayısıyla veri kaybı riski neredeyse ortadan kalkar ve her düğüm yazma kabul edebilir. Buna karşılık Galera her commit için ağ turu ödediğinden tek işlem gecikmesi biraz daha yüksektir.

Galera Cluster ücretsiz mi#

Galera'nın açık kaynak sürümü ücretsizdir ve MariaDB dağıtımının içinde hazır gelir; ayrı bir lisans satın alman gerekmez. Percona XtraDB Cluster de aynı Galera kütüphanesini kullanır ve açık kaynaktır. Ücretli olan kısım yalnızca üretici firmaların sunduğu destek ve danışmanlık paketleridir; teknolojinin kendisi için ödeme yapmazsın.

Bir düğüm kümeye katılmıyorsa nasıl kontrol ederim#

Önce journalctl -u mariadb -f ile o düğümün günlüğünü canlı izle; Galera hata mesajlarını oldukça açık yazar. Ardından 4567, 4568 ve 4444 portlarının diğer düğümlerden erişilebilir olduğunu doğrula, çünkü katılamama sorunlarının büyük çoğunluğu güvenlik duvarı kaynaklıdır. Son olarak wsrep_cluster_name değerinin üç düğümde de birebir aynı yazıldığından emin ol; tek harflik fark bile düğümün ayrı bir küme kurmasına yol açar.

Galera üzerinde yazmaları tüm düğümlere dağıtmalı mıyım#

Teknik olarak dağıtabilirsin ama pratikte önerilmez. Aynı satırlara farklı düğümlerden eşzamanlı yazmak certification failure denen geri almaları artırır ve uygulamanın deadlock görmesine yol açar. Yaygın kurgu, yazmaları tek bir düğüme yönlendirip okumaları üçe dağıtmaktır; bu hem çakışmayı bitirir hem de okuma kapasitesini üçe katlar. Yönlendirmeyi ProxySQL gibi bir katman otomatik yapabilir.

SST ne kadar sürer ve bu sırada küme çalışır mı#

SST süresi tamamen veri boyutuna ve ağ hızına bağlıdır; birkaç gigabaytlık bir veritabanı dakikalar sürerken yüzlerce gigabaytlık bir set saatler alabilir. mariabackup yöntemi kullanıldığında kaynak düğüm bu süre boyunca sorgu almaya devam eder, yani küme çalışır durumda kalır. rsync yöntemi ise kaynak düğümü kilitlediğinden üretimde tercih edilmemelidir.

Kapanış#

Galera Cluster, doğru kurulduğunda bir MySQL sunucusunun bakım, yeniden başlatma ve donanım arızası nedeniyle yarattığı kesinti penceresini neredeyse tamamen kapatır. Aklında tutman gereken dört alışkanlık şudur: düğüm sayısını daima tek tut, kümeye almadan önce bütün tablolara birincil anahtar ekle, kümeyi tamamen kapattıktan sonra yalnızca safe_to_bootstrap: 1 olan düğümden başlat ve yoğun yazma alan sistemlerde gcache.size değerini SST'yi önleyecek kadar büyüt. Bunların üzerine wsrep_cluster_size ve wsrep_local_state_comment değerlerini izleyen basit bir kontrol koyarsan, kümenin sağlığını gözden kaçırman zorlaşır.

Bu kurguyu kendi altyapında denemek istiyorsan üç ayrı VDS ya da esnek kaynaklı bulut sunucu paketleriyle birkaç saat içinde ayağa kaldırabilirsin. Kurulumu, izlemeyi ve düğüm bakımlarını kendin üstlenmek istemiyorsan sunucu yönetimi hizmetimiz Galera dahil veritabanı katmanını işletir; kümenin yanına ayrı bir kopya almak istersen yedekleme çözümlerimize göz atabilirsin.