MySQL Galera Cluster ile Multi-Master Replikasyon: Sürekli Veri Erişimi ve Bütünlüğü

 · 

MySQL Galera Cluster ile Multi-Master Replikasyon: Sürekli Veri Erişimi ve Bütünlüğü

MySQL Galera Cluster ile Multi-Master Replikasyon: Sürekli Veri Erişimi ve Bütünlüğü

Veritabanı sistemlerinde yüksek erişilebilirlik ve veri bütünlüğü, kritik iş yükleri için temel bir gereksinimdir. Geleneksel MySQL replikasyon yöntemleri, master-slave modeli nedeniyle tek bir yazma noktasının arızası durumunda kesinti riskini barındırır. Bu sorunu aşmak için, senkron multi-master mimarisi sunan MySQL Galera Cluster öne çıkar.

Galera Cluster Temelleri: Senkron Replikasyonun Gücü

Galera Cluster, Percona XtraDB Cluster ve MariaDB Galera Cluster gibi dağıtımların temelini oluşturan, sertifikasyon tabanlı replikasyon protokolünü kullanan bir veritabanı kümeleme çözümüdür. Bu mimaride, kümedeki her düğüm aktif bir master olarak görev yapar ve tüm düğümler yazma işlemlerini eş zamanlı olarak kabul edebilir. En önemli özelliği, işlemlerin kümenin tüm düğümlerinde aynı anda (fiziksel olarak değil, mantıksal olarak) işlenmesini garanti eden senkron replikasyondur. Bir işlem onaylandığında, verinin kümedeki tüm düğümlere tutarlı bir şekilde yazıldığı garanti edilir.

Nasıl Çalışır: Sertifikasyon ve Çatışma Çözümü

Galera, yazma işlemlerini 'write-set' olarak adlandırılan birimlerle yayar. Bir uygulama bir düğüme yazma isteği gönderdiğinde, bu işlem yerel olarak uygulanmadan önce, write-set tüm küme üyelerine gönderilir. Diğer düğümler, bu write-seti kendi verilerine uygulayabileceklerini 'sertifika' mekanizmasıyla onaylar. Eğer aynı veriye eş zamanlı olarak farklı düğümlerden yazmaya çalışan iki işlem çakışırsa, Galera'nın sertifikasyon mekanizması bir 'first-committer-wins' (ilk taahhüt eden kazanır) prensibiyle çakışmayı çözer. Bu, bir işlemin başarılı olması için diğer düğümlerden onay almasını gerektirdiğinden, geleneksel asenkron replikasyonda görülen veri tutarsızlıkları önlenir.

Bu mekanizma, özellikle SERIALIZABLE izolasyon seviyesinin küme genelinde uygulanmasına benzer bir davranış sergiler. Her düğüm, gelen write-set'i kendi işlem kuyruğuna alır ve bu write-set'lerin uygulanabilirliğini sertifika kontrolüyle belirler. Başarılı sertifikasyon sonrası, write-set tüm düğümlere uygulanır ve işlem kesinleşir.

Temel Bileşenler ve Mekanizmalar

State Transfer (SST) ve Incremental State Transfer (IST)

Yeni bir düğüm küme katıldığında veya arızadan dönen bir düğüm senkronize edilmesi gerektiğinde, Galera iki ana mekanizma kullanır:

  • SST (State Snapshot Transfer): Kümede mevcut bir düğümden tüm veri kopyasının yeni düğüme aktarılmasını sağlar. Bu genellikle rsync, XtraBackup gibi araçlarla yapılır ve büyük veritabanları için zaman alıcı olabilir.
  • IST (Incremental State Transfer): Eğer bir düğüm kısa süreli bir kesintiden sonra geri dönerse ve diğer düğümlerle arasındaki fark azsa, yalnızca kaçırılan write-set'leri aktararak hızlı bir senkronizasyon sağlar. Bu, daha verimli ve hızlı bir kurtarma yöntemidir.

Flow Control (Akış Kontrolü)

Galera Cluster, kümedeki en yavaş düğümün diğerlerini yavaşlatmasını engelleyen bir akış kontrol mekanizmasına sahiptir. Bir düğümün işlem hacmi geride kalmaya başladığında, bu düğüm diğer master'ları geçici olarak durdurarak kendi hızına yetişmesini sağlar. Bu, tüm kümenin performansı pahasına olsa da, veri bütünlüğünü garantiler.

Üretim Senaryoları ve Uygulamalar

Yüksek Erişilebilirlik Web Uygulamaları

Bir e-ticaret platformu veya finansal hizmetler uygulaması düşünün. Bu tür sistemlerde veritabanı kesintisi kabul edilemez. Galera Cluster, üç veya daha fazla düğümlü bir mimariyle, herhangi bir düğümün arızalanması durumunda otomatik olarak diğer düğümlerden hizmet vermeye devam etmesini sağlar. Bir düğüm çöktüğünde bile, uygulama kesintisiz olarak diğer aktif düğümlere bağlanmaya devam eder. Yük dengeleyiciler (örneğin HAProxy) ile entegre edildiğinde, uygulama katmanı için şeffaf bir failover sağlanır.

# HAProxy yapılandırma örneği listen mysql-cluster    bind *:3306    mode tcp    option tcp-check    balance roundrobin    server galera1 192.168.1.101:3306 check port 3306 inter 2s rise 2 fall 3    server galera2 192.168.1.102:3306 check port 3306 inter 2s rise 2 fall 3    server galera3 192.168.1.103:3306 check port 3306 inter 2s rise 2 fall 3

Yukarıdaki HAProxy yapılandırması, gelen 3306 port isteklerini üç Galera düğümüne dağıtır. Her düğümün durumu düzenli olarak kontrol edilir ve sağlıklı olmayan düğümler otomatik olarak havuzdan çıkarılır. Bu, uygulama katmanının her zaman erişilebilir bir veritabanı düğümüne yönlendirilmesini garanti eder.

Coğrafi Dağıtık ve Felaket Kurtarma

Veritabanı altyapısını farklı veri merkezlerine veya AWS bölgelerine dağıtmak, bölgesel felaketlere karşı direnç sağlamak için kritik öneme sahiptir. Galera Cluster, WAN replikasyonunu desteklemese de, genellikle her veri merkezinde ayrı bir Galera kümesi kurularak ve bu kümeler arasında MySQL asenkron replikasyonu veya daha gelişmiş çözümlerle veri senkronizasyonu sağlanarak bir felaket kurtarma stratejisi oluşturulur. Ancak, aynı küme içinde düğümleri coğrafi olarak ayırmak yüksek gecikme nedeniyle performansı düşürebilir. Bu nedenle, genellikle her bölgede tam bir küme bulundurulur ve bölgeler arası replikasyon, MySQL'in kendi asenkron mekanizmalarıyla veya DRBD gibi harici araçlarla yönetilir.

Yüksek Yazma Yükleri ve Ölçeklenebilirlik

Multi-master mimarisi, yazma işlemlerinin kümedeki herhangi bir düğüme yönlendirilebilmesi avantajını sunar. Bu, özellikle bursty (ani yoğun) yazma yükleri olan uygulamalar için faydalı olabilir. Ancak, Galera'nın senkron doğası nedeniyle, genel yazma performansı kümedeki en yavaş düğüm ve ağ gecikmesi ile sınırlıdır. Çatışma riski yüksek olan (örneğin, sık sık aynı satırı güncelleyen) uygulamalarda, performans sorunları yaşanabilir. Bu durumda, uygulama katmanında yazmaları belirli bir düğüme yönlendiren (write-affinity) veya yazma işlemlerini mümkün olduğunca dağıtan stratejiler izlemek gerekebilir.

Kurulum ve Temel Yapılandırma Adımları (3 Düğümlü Küme Örneği)

Bir 3 düğümlü Galera kümesi kurmak için temel adımlar şunlardır:

1. Paketlerin Kurulumu (Örnek: MariaDB Galera Cluster)

# Tüm düğümlerdesudo apt update sudo apt install mariadb-server mariadb-client mariadb-galera-server

2. Galera Yapılandırması (/etc/mysql/mariadb.conf.d/50-galera.cnf)

Her düğümde aşağıdaki gibi bir yapılandırma dosyası oluşturulmalıdır. IP adresleri ve düğüm isimleri her düğüme özel olarak ayarlanmalıdır.

# node1 içinsudeniz[galera]wsrep_on=ONwsrep_provider=/usr/lib/galera/libgalera_smm.sowsrep_cluster_name="my_galera_cluster"wsrep_cluster_address="gcomm://192.168.1.101,192.168.1.102,192.168.1.103"wsrep_node_name="galera1"wsrep_node_address="192.168.1.101"wsrep_sst_method=rsyncbind-address=0.0.0.0binlog_format=ROWdefault_storage_engine=InnoDBinnodb_autoinc_lock_mode=2
# node2 ve node3 için wsrep_node_name ve wsrep_node_address değerleri değiştirilmelidir.# Örneğin node2 için:wsrep_node_name="galera2"wsrep_node_address="192.168.1.102"

3. Kümenin Başlatılması

İlk düğüm (bootstrap) özel bir komutla başlatılmalıdır:

sudo galera_new_cluster# Veya manuel olarak:sudo systemctl stop mariadbsudo mysqld_safe --wsrep-new-cluster &

Diğer düğümler normal şekilde başlatılır:

sudo systemctl start mariadb

4. Küme Durumunu Kontrol Etme

mysql -u root -p -e "SHOW STATUS LIKE 'wsrep_%%';"

wsrep_cluster_size değeri 3 olmalı ve wsrep_local_state_comment değeri "Synced" olmalıdır.

Galera Cluster Kullanımının Zorlukları ve Dikkat Edilmesi Gerekenler

  • Split-Brain Riski: Kümenin network kesintisi nedeniyle ikiye bölünmesi durumunda, Galera kendiliğinden birincil bölümü seçer. Ancak düğüm sayısı tek olmalıdır (3, 5 gibi) ve küme bölümünün çoğunluğa sahip olması gerekir. Aksi takdirde, küme kilitlenebilir.
  • Write-Set Çatışmaları: Aynı satıra veya indekse aynı anda birden fazla düğümden yazma denemeleri çatışmalara yol açabilir. Yoğun çekişmeli yazma işlemleri olan uygulamalarda performansı düşürebilir.
  • WAN Gecikmesi: Senkron replikasyon, ağ gecikmesine duyarlıdır. Düğümler arası yüksek gecikme, tüm kümenin yazma performansını olumsuz etkiler. Bu nedenle, düğümlerin genellikle aynı veri merkezi veya yakın coğrafyada olması önerilir.
  • Tablo Kilitleri ve İşlem Boyutları: Galera, InnoDB motorunu kullanır ve işlem boyutlarına dikkat etmek gerekir. Çok büyük işlemler veya uzun süreli kilitler, replikasyon gecikmelerine neden olabilir.

Sonuç

MySQL Galera Cluster, yüksek erişilebilirlik ve veri bütünlüğü arayan işletmeler için güçlü bir multi-master replikasyon çözümü sunar. Senkron replikasyon, otomatik failover ve veri tutarlılığı garantisi, onu kritik üretim ortamları için cazip kılar. Ancak, mimarisinin getirdiği bazı kısıtlamalar ve performans karakteristikleri dikkate alınarak doğru senaryolarda uygulanması önemlidir. Doğru yapılandırma ve izleme ile Galera, veritabanı altyapınızın dayanıklılığını önemli ölçüde artırabilir.

← Blog Listesine Dön