İçeriğe geç
MariaDB Galera Cluster

MariaDB Galera Cluster, MariaDB node’ları arasında certification tabanlı multi-primary replikasyon sağlayan bir cluster çözümüdür. Birden fazla node yazma kabul edebilir. Transaction’ın değişikliklerini temsil eden write-set, commit sürecinde sıralanır ve diğer transaction’larla çakışma açısından kontrol edilir; bu kontrole certification denir. Resmi mimari belgesi bu süreci açıklar.

Galera, birbirinden bağımsız çalışan sunucuların sonradan veriyi birleştirdiği bir sistem değildir. Quorum, ağ gecikmesi ve transaction davranışı uygulamanın çalışmasını doğrudan etkiler. Temel motor seçimi için MariaDB / MySQL karşılaştırması ayrıca incelenebilir.

Hangi durumda Galera seçilmeli?

MariaDB üzerinde node kaybına dayanıklı bir veri katmanı ve uygun iş yükünde multi-primary erişim gerekiyorsa değerlendirilebilir. Şu koşullar seçimden önce doğrulanmalıdır:

  • Kullanılan tabloların storage engine ve primary key yapısı Galera gereksinimlerine uygun mu?
  • Uygulama transaction çakışmasında kontrollü yeniden deneme yapabiliyor mu?
  • Büyük transaction, toplu veri yükleme ve şema değişikliklerinin etkisi ölçüldü mü?
  • Uzak node’ların gecikmesi kabul edilebilir mi?
  • İşletim ekibi quorum kaybı ve tam cluster kurtarmasını yönetebiliyor mu?

Bilinen sınırlar, tablo ve transaction davranışının standalone MariaDB ile aynı kabul edilmemesi gerektiğini gösterir. Yalnız okuma replica’sı ihtiyacında daha sade bir replikasyon modeli yeterli olabilir.

Quorum ve yazma yönlendirmesi

Quorum rehberine göre eşit oy ağırlıklı üç üyeli yapıda iki üyenin iletişimde kalması çoğunluğu sağlar. Node’ların hata alanlarına yerleşimi önemlidir; aynı host üzerindeki node’lar bağımsız koruma değildir.

garbd bir arbitrator’dır: quorum hesabına katılır, veritabanı kopyası tutmaz. Primary Component, yazma kabul etmeye yetkili cluster bölümüdür; tek bir primary sunucu anlamına gelmez. Proxy’nin health check’i yalnız SQL portuna bakmamalı; node’un bu bileşen içinde, senkronize ve trafik almaya uygun olduğunu değerlendirmelidir.

Bütün node’lara yazma dağıtmak zorunlu değildir. Aynı satırlara yoğun yazılan bir uygulamada tek yazma noktası daha anlaşılır olabilir. Bu tercih çakışmaları tamamen ortadan kaldırmaz; transaction yeniden denemeleri iş kurallarını bozmamalıdır.

Senkron replikasyonun sınırları

Write-set’in cluster içinde sıralanması, başka bir node’un onu anında sorgulanabilir hâle getirmesiyle aynı değildir. Bir node’a yazıp hemen diğerinden okumak eski veri döndürebilir. Uygun wsrep_sync_wait politikası ve okuma yönlendirmesi, gecikme etkisiyle birlikte değerlendirilir.

Aynı veri üzerinde eşzamanlı transaction’lar certification hatasıyla geri alınabilir. “Multi-primary” ifadesi sınırsız paralel yazma veya bütün transaction örüntülerinde otomatik serializable davranış garantisi değildir.

Flow control, IST ve SST

IST (Incremental State Transfer) eksik değişikliklerin artımlı aktarımıdır; SST (State Snapshot Transfer) tam veri aktarımıdır. Aktarımı sağlayan node donor olarak adlandırılır.

Mekanizmaİşletim açısından anlamı
Flow controlGeride kalan node, yeni replikasyon akışını yavaşlatabilir; bütün cluster etkilenebilir.
ISTUygun geçmiş GCache içinde mevcutsa eksik write-set’lerle yeniden katılım sağlar.
SSTIST mümkün değilse tam veri aktarımı gerekebilir; ağ, disk ve donor yükü planlanır.
GCacheYeniden katılım için tutulan write-set geçmişidir; bağımsız yedek değildir.

Flow control belgesi, yavaş node’un neden araştırılması gerektiğini; IST/GCache rehberi ise artımlı yeniden katılımın önkoşullarını açıklar. Eşik yükseltmek veya node eklemek sorunun kaynağını kendiliğinden çözmez.

Kurtarma ve bakım planı

Yedek alınacak node, yedek aracı ve PITR kapsamı belirlenir. Tam cluster kaybında en ileri veri durumunun tespiti ve tek bir kontrollü bootstrap yolu belgelenir. Ağ bölünmesinin iki tarafında ayrı ayrı bootstrap yapılmaz.

Pilot; node kaybı, ağ bölünmesi, uzun kesinti sonrası SST, şema değişikliği ve yedekten geri yüklemeyi kapsamalıdır. RPO/RTO, cluster’ın ayağa kalkmasının yanında uygulamanın doğru veriyle çalışması üzerinden ölçülür.

İlgili hizmetlerimiz

Sıkça sorulan sorular

Galera'da bütün node'lara yazmak zorunlu mu?
Hayır. Multi-primary yeteneği bulunması uygulamanın her node’a yazmasını gerektirmez. Tek yazma noktası kullanmak bazı iş yüklerinde çakışma yönetimini kolaylaştırabilir; yönlendirme ve failover ayrıca tasarlanır.
İki node yeterli mi?
Eşit oy ağırlıklı iki node’dan biri kaybolursa çoğunluk kalmaz. Üçüncü veri node’u veya uygun bir arbitrator tasarımı değerlendirilir. garbd oy verir ama veri kopyası tutmaz; yedek veya replica yerine geçmez.
Senkron replikasyon her node'da anında güncel okuma demek mi?
Hayır. Write-set’in sıralanması ve certification ile işlemin başka node’da uygulanması farklı aşamalardır. Node’lar arası read-after-write beklentisi için wsrep_sync_wait gibi mekanizmalar ve uygulama yönlendirmesi değerlendirilmelidir.
Galera cluster'ı yeniden başlatmak veri kurtarma mıdır?
Tam cluster kaybında doğru bootstrap node’u seçilmelidir. Rastgele veya birden fazla tarafta bootstrap yapmak veri ayrışmasına yol açabilir. Önce mevcut durum ve en ileri veri konumu incelenir; yedek ve kurtarma planı korunur.

Bir sonraki dönüşümü birlikte planlayalım.

Ekibimiz teknik gereksinimlerinizi anlamak ve hızlıca prototip çıkarmak için hazır.