- Konu sahibi
- #1
MySQL Cluster nedir?
MySQL Cluster, MySQL verisini birden fazla sunucuya dağıtarak yüksek erişilebilirlik ve yatay ölçekleme sağlamayı amaçlayan dağıtık veritabanı mimarisidir. Ancak “MySQL cluster” ifadesi iki farklı anlamda kullanılabilir: Resmî ürün olan MySQL NDB Cluster veya InnoDB tabanlı birden fazla MySQL sunucusundan oluşan genel küme yapıları. Bu ikisi aynı çalışma modeline sahip değildir.
NDB Cluster’da veri, kümedeki veri düğümlerinde dağıtılır ve çoğaltılır. SQL düğümleri uygulamaların bağlandığı MySQL sunucularıdır; yönetim düğümleri ise kümenin yapılandırılmasını ve düğüm yönetimini sağlar. Bir veri düğümü kaybında gerekli veri kopyaları, düğüm grupları ve kümenin arbitraj koşulları sağlanıyorsa hizmet devam edebilir; yalnız bir kopyanın herhangi bir yerde bulunması tek başına yeterli garanti değildir. Bunun karşılığında uygulamanın sorgu modeli, tablo tasarımı, ağ gecikmesi ve operasyon yükü tek sunuculu MySQL’den daha dikkatli ele alınmalıdır.
MySQL Cluster nasıl çalışır?
Klasik NDB Cluster mimarisinde görevler ayrıdır:
- SQL düğümleri: Uygulamaların bağlandığı MySQL sunucularıdır ve SQL sorgularını çalıştırır.
- Veri düğümleri: Veriyi tutar, parçalar ve yapılandırmaya göre yedekli kopyalar oluşturur.
- Yönetim düğümleri: Küme yapılandırmasını ve düğümlerin koordinasyonunu sağlar; genellikle uygulama trafiğinin ana hedefi değildir.
Örneğin bir sipariş uygulamasında iki SQL düğümü, en az iki veri düğümü ve ayrı bir yönetim düğümü düşünülebilir. Uygulama SQL düğümlerinden birine bağlanır. Bu SQL düğümü kapanırsa bağlantı havuzu veya yönlendirme katmanı diğer SQL düğümüne geçebilir. Bir veri düğümü kapanırsa, gerekli veri başka bir kopyada mevcutsa küme çalışmayı sürdürebilir. Bu, uygulamanın bağlantı yeniden denemesini ve hata durumunu doğru yönetmesini yine de gerektirir.
Bu yapı, yalnızca aynı veritabanını iki sunucuda çalıştırmak değildir. Düğümler arası ağ, veri kopyalarının oluşması, düğüm sayısı, bölümleme ve istemci yönlendirmesi birlikte tasarlanır. Ağ kesintisi veya yetersiz kaynaklar, teorik yüksek erişilebilirliği pratikte bozabilir.
NDB Cluster mı, InnoDB tabanlı çözüm mü?
“Cluster” seçimi önce iş yüküne göre yapılmalıdır. Aşağıdaki ayrım karar vermeyi kolaylaştırır:
| Yapı | Temel yaklaşım | Ne zaman değerlendirilir? |
|---|---|---|
| MySQL NDB Cluster | Veri düğümleri arasında dağıtılmış ve yedekli çalışma | Düşük gecikmeli, yüksek erişilebilirlik isteyen ve NDB kısıtlarını karşılayabilen özel iş yüklerinde |
| MySQL Group Replication / InnoDB Cluster | InnoDB kullanan MySQL sunucularının grup halinde çoğaltılması | Mevcut InnoDB uygulamasını koruyarak yüksek erişilebilirlik ve kontrollü yazma yönlendirmesi gerektiğinde |
| Asenkron replikasyon | Bir sunucudaki değişikliklerin diğerine aktarılması | Okuma ölçekleme, yedek sunucu veya raporlama gibi daha basit ihtiyaçlarda |
Bu seçenekler birbirinin otomatik yerine geçmez. NDB Cluster’a geçmek, yalnızca sunucu sayısını artırmak değildir; desteklenen veri türleri, indeksler, sorgu planları, işlemler ve uygulama davranışı ayrıca test edilmelidir. InnoDB Cluster; Group Replication, MySQL Shell yönetimi ve MySQL Router yönlendirmesini birlikte kullanır. Varsayılan single-primary yapıda primary kaybında uygun secondary otomatik primary olabilir ve Router yeni bağlantıları ona yönlendirir. Buna rağmen kopan bağlantıyı yeniden kurmak ve sonucu belirsiz kalan işlemi güvenli ele almak uygulama/istemci sorumluluğudur.
Doğru seçimi yapmak için izlenecek yol
- Önce hedefi netleştirin: Kesintisiz hizmet mi, yazma kapasitesi mi, okuma ölçekleme mi, yoksa felaket kurtarma mı istediğinizi belirleyin.
- Mevcut uygulamanın InnoDB bağımlılıklarını, işlem davranışını, sorgu sürelerini ve kullandığı MySQL özelliklerini envanterleyin.
- NDB Cluster düşünülüyorsa tabloları, indeksleri, bölümleme yaklaşımını ve uygulamanın ağ gecikmesine duyarlılığını ayrı bir test ortamında doğrulayın.
- İstemci bağlantı havuzunu, düğüm arızasında yeniden bağlanmayı ve yazma trafiğinin hangi düğüme gideceğini tasarlayın.
- Tek tek sunucu arızası, ağ kopması, veri düğümü kaybı ve yeniden başlatma senaryolarını test edin; yalnızca kümenin ayakta kalmasını değil, uygulamanın doğru sonuç vermesini de kontrol edin.
- Son olarak yedekleme, geri yükleme, izleme ve sürüm yükseltme prosedürlerini kümenin tamamı için belgeleyin.
En yaygın hata, “iki MySQL sunucusu kurulduysa otomatik olarak cluster oluşur” varsayımıdır. Replikasyon gecikmesi, yanlış bağlantı yönlendirmesi, tekil ağ veya yönetim noktası ve test edilmemiş failover bu varsayımı boşa çıkarabilir. Ayrıca yüksek erişilebilirlik, yedeklemenin alternatifi değildir; yanlışlıkla silinen veri veya uygulama kaynaklı hatalı işlem çoğu zaman tüm kopyalara yayılabilir.
MySQL Cluster adı ürün bağlamında NDB Cluster’a işaret eder; günlük kullanımda genel MySQL kümesi için de söylenebilir. Önce hangi anlamın kastedildiğini ve hedefin ne olduğunu belirleyin; ardından NDB, InnoDB Cluster ya da daha basit replikasyon seçeneklerinden gereksinimlerinize uyanı test ederek seçin.
Sık sorulan sorular
MySQL Cluster ile MySQL replikasyonu aynı şey midir?
Hayır. Replikasyonda bir sunucudaki değişiklikler başka sunuculara aktarılır. Cluster mimarisinde ise düğümlerin rolü, veri kopyalarının çalışma biçimi, istemci yönlendirmesi ve hata yönetimi birlikte tasarlanır. Bazı cluster çözümleri replikasyon kullanabilir, fakat her replikasyon kurulumu cluster değildir.
Cluster kurunca bütün sorguları yeniden yazmak gerekir mi?
Her durumda bütün sorguları değiştirmek gerekmez; ancak seçilen motor ve mimariyle uyumluluk test edilmelidir. Bağlantı yeniden denemesi, düğüm değişiminde trafik yönlendirme, işlem tekrarlarının güvenli olması ve zaman aşımı ayarları uygulama veya bağlantı katmanında ele alınmalıdır. Mevcut sorguların ve tablo yapısının seçilen cluster teknolojisiyle uyumlu olduğu da doğrulanmalıdır.
