Yüksek Erişilebilirlik ve Cluster Çözümleri
Bir veritabanı sunucusu er ya da geç erişilemez duruma gelir. Belirleyici olan sistemin arızayı kaç saniyede fark ettiği ve devralmayı otomatik yapıp yapmadığıdır.
Kesintisiz veritabanı mimarisi kuruyoruz
Cluster kurmak yetmez; devralmanın çalıştığı kanıtlanmalıdır. Mimariyi tasarlar, kurar ve devralma senaryolarını tatbikatla doğrularız.
Topoloji tasarımı
Senkron mu asenkron replikasyon, kaç düğüm, hangi veri merkezinde. Kararlar RPO hedefinize ve kabul ettiğiniz gecikme bütçesine göre alınır; hazır bir şablon uygulanmaz.
Quorum ve split-brain
Çift düğümlü kurulumlar ağ bölünmesinde karar veremez. Düğüm sayısını, oy hakkını ve gerektiğinde tanık (arbitrator) düğümü, ağ bölünmesi senaryosunda kümenin tek bir karar üretmesini sağlayacak biçimde tasarlıyoruz.
Trafik yönlendirme
Devralma tamamlansa bile uygulama eski birincil düğüme bağlanmaya devam ediyorsa kesinti sürüyor demektir. ProxySQL, MySQL Router ve HAProxy ile bağlantı katmanını devralmaya duyarlı hâle getiriyoruz.
Devralma tatbikatı
Denenmemiş devralma, çalıştığı varsayılan devralmadır. Planlı tatbikatlarla devralma süresini ölçüyor, uygulama tarafındaki yeniden bağlanma davranışını birlikte gözlemliyoruz.
Erişilebilirlik hedefi, mimariyi belirler
Yüksek erişilebilirlik çalışmaları da yedekleme gibi araç seçimiyle değil, hedef belirlemeyle başlar. Sorulması gereken soru şudur: sistemin kabul edilebilir kesinti süresi kaç saniyedir ve devralma sırasında veri kaybı tolere edilebilir mi?
Senkron replikasyon veri kaybını ortadan kaldırır; buna karşılık her yazma işlemine ağ gecikmesi ekler. Asenkron replikasyon yazma performansını korur; ancak devralma anında henüz kopyalanmamış işlemler kaybedilebilir. İki yaklaşımdan hangisinin doğru olduğu iş gereksinimine bağlıdır ve karar teknik ekipten önce iş birimlerini ilgilendirir.
Mimariyi hazır bir şablona göre değil, belirlenen hedeflere göre tasarlıyoruz.
MySQL InnoDB Cluster Danışmanlık ve MariaDB Galera Cluster kurulumları
MySQL InnoDB Cluster, Group Replication üzerine kurulu ve MySQL Router ile birlikte çalışan bütünleşik bir çözümdür. Grup üyeliği, otomatik devralma ve kurtarma süreçleri MySQL tarafından yönetilir; yönetim işlemleri MySQL Shell üzerinden yürütülür. Ekosistem içinde kalmak isteyen kurumlar için en düşük sürtünmeli seçenektir.
Group Replication, InnoDB Cluster’ın altında yer alan çoğaltma katmanıdır ve tek başına da kullanılabilir. Yazma işlemleri grup düğümleri arasında oy birliği (consensus) ile onaylanır; böylece veri tutarlılığı düğüm arızalarında da korunur.
Galera Cluster, MariaDB ve Percona XtraDB Cluster dağıtımlarında kullanılan çoklu birincil (multi-master) çözümdür. Her düğüm yazma kabul edebilir; ancak bu esneklik uygulama tarafında çakışma (conflict) yönetimi gerektirebilir. Uygulamanın yazma desenini incelemeden çoklu birincil topoloji önermiyoruz; birçok senaryoda tek yazma düğümü ile çalışan bir Galera kurulumu daha öngörülebilir davranır.
ProxySQL ve MySQL Router, bağlantı katmanını devralmaya duyarlı hâle getirir. Cluster mimarisinin değeri, uygulamanın yeni birincil düğümü bulabilmesine bağlıdır; yönlendirme katmanı olmadan devralma tamamlansa bile kesinti devam eder.
PostgreSQL Patroni Cluster Kurulum ve Yönetim
PostgreSQL için Patroni kullanıyoruz. Patroni, streaming replication üzerine otomatik devralma yeteneği ekleyen bir küme yöneticisidir; küme durumunu etcd, Consul veya ZooKeeper üzerinde tutarak hangi düğümün birincil olduğu konusunda tek bir doğruluk kaynağı oluşturur.
Kurulumda kritik olan bileşen, dağıtık yapılandırma deposunun (DCS) kendisidir: küme kararı orada üretildiği için deponun kendisi de yüksek erişilebilir olmalıdır. Tek düğümlü bir etcd kurulumu üzerine inşa edilmiş bir Patroni kümesi, tek arıza noktasını veritabanından yapılandırma deposuna taşımaktan başka bir işe yaramaz.
Bağlantı yönlendirmesi HAProxy ile Patroni’nin sağlık uçlarına (health check endpoint) bağlanarak kurulur; böylece uygulama her zaman güncel birincil düğüme yönlendirilir.
MongoDB tarafında ReplicaSet ve sharding
MongoDB’de yüksek erişilebilirlik ReplicaSet yapısıyla sağlanır. Üyeler arasında birincil seçimi otomatik yürütülür; seçimin sağlıklı sonuçlanması için tek sayıda oy hakkı bulunması gerekir. Çift üyeli kurulumlarda tanık (arbitrator) üye ekleyerek karar mekanizmasını tamamlıyoruz.
Veri hacmi tek küme kapasitesini aştığında sharding devreye girer. Shard anahtarının seçimi, sonradan değiştirilmesi maliyetli bir karardır ve dağılımı bozuk bir anahtar tüm yükü tek shard üzerinde toplayabilir. Anahtar seçimini sorgu desenlerinizi inceleyerek yapıyoruz.
Kurulan mimariyi tatbikatla doğruluyoruz
Sahada en sık karşılaştığımız durum, kurulumu tamamlanmış ancak devralması hiç denenmemiş cluster yapılarıdır. Devralma mekanizması, ilk kez gerçek bir arıza anında denendiğinde beklenen davranışı göstermeyebilir: yönlendirme katmanı güncellenmez, uygulama bağlantı havuzu eski düğümde ısrar eder veya kurtarma süreci beklenenden uzun sürer.
Kurduğumuz her mimaride planlı devralma tatbikatı yürütüyoruz. Tatbikat sırasında devralma süresi ölçülür, uygulama tarafındaki yeniden bağlanma davranışı gözlemlenir ve sonuçlar raporlanır. Ölçülen süre, kurumun gerçek RTO değerine yaptığı katkıdır.
İlgili hizmetler
Cluster mimarisi yedeklemenin yerini almaz; ikisi birlikte kurgulanır: Veritabanı Yedekleme ve Kurtarma
Denetim kaydı ve şifreleme yapılandırmaları tüm düğümlere tutarlı biçimde uygulanmalıdır: Veritabanı Güvenliği ve KVKK Teknik Tedbirleri
Replikasyon gecikmesi ve düğümler arası yük dağılımı performans çalışmasının kapsamındadır: Performans Optimizasyonu ve İzleme
Veritabanı destek hizmetlerimiz
Cluster mimarisi kurduğumuz veritabanlarında destek ve danışmanlık hizmetlerimizin tamamını sunuyoruz.
MySQL Destek
Performans, cluster, yedekleme ve güvenlik başlıklarının tamamı tek kapsamda; Percona Server geçişi dahil.
PostgreSQL Destek
Patroni cluster kurulumu ve yönetimi, pgBackRest ile yedekleme, sorgu ve yapılandırma optimizasyonu.
MariaDB Destek
Galera Cluster kurulumu, sürüm yükseltmeleri ve operasyonel bakım.
MongoDB Destek
ReplicaSet ve sharding kurulumu, izleme altyapısı ve bakım.
Sık sorulan sorular
DROP TABLE komutu tüm düğümlere anında yayılır. Yüksek erişilebilirlik ve yedekleme farklı problemleri çözer; ikisinin birlikte kurgulanması gerekir. Yedekleme ve kurtarma tarafını ayrıca planlıyoruz.