İlk MariaDB Galera Cluster'ımdan Önce Bilmeyi Dilediğim Şeyler
Galera Cluster'ın vaadi cazip: birden fazla MariaDB node'u, hepsi yazılabilir, hepsi senkron şekilde sync'li, replication lag yok, "hangi node'da en güncel data var" sorusu yok. Bunların hepsi doğru. Pitch'in vurgulamadığı şey, "synchronous" ve "multi-master"ın ikisinin de, iki node'lu ve gerçek traffic'i olmayan bir demo'da değil, production'da kendini gösteren consequence'larla geldiği. Bunların hiçbiri Galera'dan kaçınmak için bir sebep değil, ama bilseydim ilk günden itibaren onlara göre configure ederdim.
Quorum, gerçek minimumun üç node olduğu anlamına geliyor
Galera, bir network split'inden sonra bir node'un, ya da bir node grubunun, çalışmaya devam etmesine izin verilip verilmeyeceğine karar vermek için quorum kullanıyor, node'ların bir çoğunluğu birbirini görebilmeli. İki node'la, ikisinden birini kaybetmek, kalan node'un bir çoğunluk oluşturamaması ve write'ları kabul etmeyi durdurması demek, iki node size high availability değil, replication veriyor. Pratik minimum üç, ve üçüncü node'un diğer ikisi kadar güçlü olmasına gerek yok, daha küçük bir "arbitrator" node'u (Galera'nın lightweight arbitrator daemon'u garbd kullanarak) tam bir data kopyası tutmadan sadece quorum'u maintain etmeye hizmet edebilir.
Her write en yavaş node'u bekliyor
Synchronous replication, bir commit'in tüm node'lar onu certify edene kadar acknowledge edilmemesi demek, yani cluster'ın write performansı en yavaş node ve node'lar arasındaki network latency'siyle sınırlı. Tüm node'lar aynı datacenter'da, aralarında sub-millisecond latency'yle olduğunda bu sorun değil. Biri "redundancy için" bir Galera node'unu farklı bir region'a koymayı önerdiğinde bu çok belirgin hale geliyor, cluster boyunca her write artık o node'a bir round trip'i bekliyor, ve cluster'ın write throughput'u buna göre düşüyor. Galera'yla geographic distribution mümkün, ama bu içine kazara sürüklenecek bir şey değil, bilinçli bir mimari karar.
Şema değişiklikleri sadece bir ALTER TABLE değil, bir plan gerektiriyor
Galera'da büyük bir tabloda düz bir ALTER TABLE, değişiklik süresince tüm cluster'ı kilitleyebilir, her node bunu varsayılan olarak Total Order Isolation üzerinden uyguluyor ve bu tamamlanana kadar cluster boyunca write'ları bloke ediyor. Küçük bir tablonun ötesindeki her şey için, Rolling Schema Upgrade (RSU) daha iyi bir yaklaşım: değişikliği node'a node'a uygulamak, bu node işlerken cluster'dan geçici olarak desync olmuş halde:
SET SESSION wsrep_OSU_method='RSU';
ALTER TABLE large_table ADD COLUMN new_field VARCHAR(255);
Her node için tekrarlayın. Alter'ı çalıştıran node kısa süreliğine sync dışı (ve ideal olarak bu süre boyunca load balancer'ın rotation'ından çıkarılmış olmalı), ama cluster'ın geri kalanı bu süre boyunca trafiği normal şekilde sunmaya devam ediyor. Birkaç milyon satırlı bir tabloda varsayılan method'la rutin bir ALTER TABLE çalıştırdığım ilk seferde, tüm cluster bu süre boyunca durdu, bunu öğrenmenin unutulmaz bir yolu oldu.
wsrep_local_state_comment, önem taşıyan status satırı
Galera node'ları process açısından "up" olabilir ama gerçekte çalışan bir cluster'ın parçası olmayabilir, joining, donor/desynced, ya da bir error state'te olabilir. Özellikle bir node restart olduktan hemen sonra kontrol edilecek en kullanışlı şey:
SHOW STATUS LIKE 'wsrep_local_state_comment';
SHOW STATUS LIKE 'wsrep_cluster_size';
wsrep_local_state_comment'in Synced göstermesi gerekiyor, ve wsrep_cluster_size'ın beklediğiniz node sayısıyla eşleşmesi gerekiyor. Bir crash'ten sonra restart olmuş ve Joining ya da Donor/Desynced gösteren bir node, recovery'nin ortasında (potansiyel olarak başka bir node'dan kendi başına bir load event olan full bir state transfer yapıyor), MariaDB'nin kendisi basit bir connection'a cevap veriyor olsa bile henüz trafiğe hazır değil.
Bunların hiçbiri Galera kullanmamak için bir sebep değil
Bunların her biri, orada olduğunu bildiğinizde yönetilebilir: gerçek quorum için üç node (ya da iki node plus bir arbitrator), node'ları network'te birbirine yakın tutmak, trivial olmayan her şey için schema değişikliklerinde RSU kullanmak, ve her health check'in parçası olarak ya da her restart'tan sonra wsrep_local_state_comment'i kontrol etmek. Galera, synchronous multi-master replication konusunda gerçekten vaadini tutuyor, can alıcı nokta sadece "synchronous" ve "multi-master"ın, tam olarak bu dört noktayı önemli kılan özellikler olması, bunlar Galera'yı baştan beri kullanmaya değer kılan şeyin maliyeti.