İlk MariaDB Galera Cluster'ımdan Önce Bilmeyi Dilediğim Şeyler

Galera Cluster'ın vaatleri inanılmaz derecede çekicidir: Hepsi yazılabilir, hepsi birbiriyle senkronize, sıfır replikasyon gecikmesi (lag) ve "hangi düğümde en güncel veri var" paniğinin olmadığı çok sayıda MariaDB düğümü (node). Bunların hepsi gerçekten de doğrudur.

Ancak bu satış konuşmasının (pitch) kesinlikle vurgulamadığı şey, "senkron" ve "multi-master" olmanın, sıfır trafikli iki düğümlü steril bir demoda değil, doğrudan üretim ortamında (production) ortaya çıkan o acımasız bedellerle birlikte gelmesidir. Bunların hiçbiri Galera'dan kaçınmak için bir neden değildir, ancak eğer en baştan bilseydim, mimariyi kesinlikle ilk günden bunlara göre yapılandırırdım.

Çoğunluk (Quorum) kuralı, gerçek minimumun üç düğüm olduğu anlamına gelir

Galera, bir ağ bölünmesi (network split) sonrasında bir düğümün veya düğüm grubunun çalışmaya devam edip edemeyeceğine karar vermek için katı bir şekilde çoğunluk (quorum) kuralını kullanır. Düğümlerin çoğunluğu fiziksel olarak birbirini görebilmelidir.

İki düğümlü bir yapıda, herhangi birini kaybetmek, geriye kalan düğümün kelimenin tam anlamıyla çoğunluğu oluşturamaması ve yazma (write) işlemlerini anında durdurması anlamına gelir. İki düğüm size yüksek erişilebilirlik (high availability) değil, sadece replikasyon sağlar. Pratik olarak minimum sayı üçtür. Ancak, bu üçüncü düğümün diğer ikisi kadar güçlü olmasına zerre kadar gerek yoktur. Sadece çoğunluğu sağlamaya yarayan ve hiçbir veri kopyası barındırmayan küçük bir "hakem" düğümü (Galera'nın o hafif garbd servisini kullanarak), bu işi mükemmel bir şekilde yapar.

Her bir yazma işlemi en yavaş düğümü bekler

Senkron replikasyon, bir commit (yazma onayı) işleminin, tüm düğümler onu açıkça onaylayana (certify) kadar gerçekleşmemesi demektir. Bu da, cluster'ınızın yazma performansının tam olarak en yavaş düğümünüz ve düğümleriniz arasındaki en kötü ağ gecikmesi (latency) ile katı bir şekilde sınırlandığı anlamına gelir.

Bu durum, tüm düğümlerinizin tıpatıp aynı veri merkezinde olduğu ve aralarında milisaniyenin altında bir gecikme bulunduğu durumlarda kesinlikle sorunsuzdur. Ancak birisi "yedeklilik (redundancy) olsun" diye tamamen farklı bir bölgeye (region) bir Galera düğümü koymayı önerdiğinde, bu acı verici bir şekilde hissedilir. Artık tüm cluster genelindeki her bir yazma işlemi, o uzaktaki düğüme gidip gelmeyi beklemek zorundadır ve cluster'ın yazma kapasitesi (throughput) de buna uyacak şekilde dramatik bir düşüş yaşar. Galera ile coğrafi dağılım (geographic distribution) kesinlikle mümkündür, ancak bu bilinçli alınmış bir mimari karardır; öylece dikkatsizce içine düşülecek bir şey değildir.

Şema değişiklikleri sadece bir ALTER TABLE değil, bir plan gerektirir

Galera'daki devasa bir tabloda çalıştırılacak sıradan bir ALTER TABLE komutu, değişiklik süresince tüm cluster'ı şiddetli bir şekilde kilitleyebilir (lock). Varsayılan olarak her bir düğüm bunu "Total Order Isolation" (Tam Sıralı İzolasyon) yöntemiyle uygular, yani işlem tamamen bitene kadar tüm cluster genelindeki yazma işlemlerini tamamen bloke eder.

Küçücük bir tablodan daha büyük olan her şey için RSU (Rolling Schema Upgrade), çok daha iyi bir yaklaşımdır. Değişikliği her seferinde tam olarak tek bir düğüme uygularsınız ve o düğüm değişikliği işlerken cluster ile olan senkronizasyonunu geçici olarak durdurur:

SET SESSION wsrep_OSU_method='RSU';
ALTER TABLE large_table ADD COLUMN new_field VARCHAR(255);

Bunu her bir düğüm için dikkatlice tekrarlayın. Değişikliği (alter) çalıştıran düğüm kısa bir süreliğine senkronizasyon dışı kalır (ve ideal olarak o süre boyunca yük dengeleyicinin (load balancer) rotasyonundan aktif olarak çıkarılır), ancak cluster'ın geri kalanı bu süre zarfında tamamen normal bir şekilde trafik sunmaya devam eder. Varsayılan yöntemi kullanarak milyonlarca satırlık bir tabloda sıradan bir ALTER TABLE komutunu ilk çalıştırdığımda, tüm cluster o süreç bitene kadar tamamen duraklamıştı; ki bu, bunu öğrenmenin inanılmaz derecede unutulmaz bir yoluydu.

Gerçekten önemli olan durum (status) satırı: wsrep_local_state_comment

Galera düğümleri, bir Linux süreci (process) açısından "ayakta" (up) görünürken, aslında çalışan bir cluster'ın parçası olmayabilirler. Katılma aşamasında (joining), veri sağlayan (donor), senkronizasyonu kopmuş (desynced) veya sert bir hata durumunda (error state) olabilirler. Özellikle bir düğüm yeniden başladıktan (restart) hemen sonra kontrol edilecek açık ara en faydalı şey şudur:

SHOW STATUS LIKE 'wsrep_local_state_comment';
SHOW STATUS LIKE 'wsrep_cluster_size';

wsrep_local_state_comment gururla Synced (Senkronize) yazmalıdır ve wsrep_cluster_size beklediğiniz düğüm sayısıyla mükemmel bir şekilde eşleşmelidir. Bir çökmeden (crash) sonra yeniden başlayan ve o an Joining veya Donor/Desynced gösteren bir düğüm, henüz kurtarma (recovery) aşamasının ortasındadır. Potansiyel olarak başka bir düğümden devasa bir veri aktarımı (state transfer) gerçekleştiriyordur (ki bu başlı başına bilinmesi gereken ağır bir yük olayıdır) ve MariaDB'nin kendisi basit bir bağlantıya mutlu mesut yanıt verse bile henüz trafiği karşılamaya hazır değildir.

Bunların hiçbiri Galera kullanmamak için bir neden değildir

Orada olduklarını bildiğiniz sürece bu şeylerin her birisi tamamen yönetilebilir (manageable) durumlardır. Gerçek bir çoğunluk (quorum) için üç düğüm (veya iki artı bir hakem) kullanın. Düğümleri ağ üzerinde fiziksel olarak birbirine yakın tutun. Basit olmayan her şema değişikliği için RSU kullanın. Herhangi bir sağlık kontrolünün (health check) katı bir parçası olarak veya herhangi bir yeniden başlatma (restart) sonrasında mutlaka wsrep_local_state_comment değerini kontrol edin.

Galera, senkron multi-master replikasyon vaadini kesinlikle yerine getirir. Tek pürüz, o dört maddenin bu kadar önemli olmasının nedeninin tam da "senkron" ve "multi-master" özellikleri olmasıdır. Bunlar, Galera'yı en başta kullanmaya değer kılan o muhteşem şeyin sadece bedelidir.