MariaDB Destek ve Danışmanlık

MariaDB, MySQL kod tabanından ayrılalı uzun zaman oldu: cluster mimarisi, yedekleme aracı ve şifreleme yaklaşımı artık MySQL'inkinden farklıdır ve destek de bu farkı bilerek verilmelidir.

$ mariadb -e "SHOW GLOBAL STATUS LIKE 'wsrep_%'" | grep -E 'cluster_size|state_comment|flow_control'
wsrep_cluster_size 3
wsrep_local_state_comment Synced
wsrep_flow_control_paused 0.31
→ akış denetimi devrede: yavaş düğüm kümenin tamamını yavaşlatıyor

MariaDB sistemlerinizi uçtan uca yönetiyoruz

MariaDB'nin araç seti kendine özgüdür. MySQL için yazılmış bir yedekleme prosedürü burada çalışmaz, MySQL'in cluster çözümü burada bulunmaz. Dört başlığı MariaDB'nin kendi araçlarıyla yürütüyoruz.

Performans optimizasyonu

MariaDB kendi sorgu optimize edicisini kullanır; aynı sorgu MySQL'de farklı bir yürütme planı (execution plan) üretebilir. Planları MariaDB üzerinde inceliyor, indeks tasarımını ve bellek ayrımını iş yüküne göre düzenliyoruz.

Galera Cluster

Kurulumu, düğüm sayısını ve durum aktarım (SST) stratejisini birlikte tasarlıyoruz. Akış denetimi (flow control) davranışını izliyor, devralma senaryolarını tatbikatla doğruluyoruz.

Yedekleme ve kurtarma

MariaDB'de mariabackup kullanılır; MySQL için geliştirilen Percona XtraBackup güncel MariaDB sürümlerinde çalışmaz. Fiziksel (physical) yedeklemeyi mariabackup ile, PITR (Point-in-Time Recovery) yeteneğini binary log arşivlemesiyle sağlıyoruz.

Güvenlik ve KVKK teknik tedbirleri

MariaDB'de disk üzerinde şifreleme ve denetim kaydı (audit logging) çekirdekte yer alır; ayrı bir dağıtıma geçmek gerekmez. file_key_management ve server_audit bileşenlerini anahtar yönetimi ve saklama politikasıyla birlikte yapılandırıyoruz.

MariaDB artık MySQL’in bir sürümü değil

MariaDB, MySQL kod tabanından çatallanarak doğdu ve ilk yıllarda iki ürün büyük ölçüde yer değiştirebilir durumdaydı. O dönem geçti. Bugün sorgu optimize edicileri farklı planlar üretiyor, JSON verisini ele alışları ayrışmış durumda, GTID uygulamaları birbiriyle uyumlu değil ve yüksek erişilebilirlik çözümleri tamamen farklı mimarilere dayanıyor.

Bu ayrışmanın destek açısından pratik karşılığı nettir: MySQL için yazılmış bir prosedür MariaDB’de olduğu gibi çalışmaz. Yedekleme betiği farklı bir araç çağırır, cluster kurulumu farklı bir teknolojiye dayanır, şifreleme farklı bir yerden gelir. Sahada gördüğümüz sorunların önemli bölümü, iki ürünün hâlâ aynı şey sanılmasından doğuyor.

MySQL’den MariaDB’ye geçişi mümkün görüyoruz ve yürütüyoruz; ancak sürücü değiştirmek olarak değil, uyumluluk taraması yapılan ve test ortamında provası alınan bir proje olarak planlıyoruz.

Galera Cluster: MariaDB’nin yüksek erişilebilirlik yanıtı

MariaDB’de InnoDB Cluster ve Group Replication bulunmaz; yüksek erişilebilirlik Galera Cluster ile sağlanır ve Galera sunucuya yerleşik olarak gelir.

Galera senkron ve sertifikasyon tabanlı çalışır. Bir işlem, kümedeki tüm düğümlere iletilip çakışma denetiminden geçmeden onaylanmaz. Sonuç, devralma anında veri kaybı olmamasıdır. Karşılığında iki davranışın baştan bilinmesi gerekir.

Akış denetimi (flow control). Bir düğüm kümeye yetişemediğinde, geride kalmasını önlemek için tüm kümeyi yavaşlatır. Üç düğümlü bir kurulumda en yavaş düğüm, kümenin yazma performansını belirler. Diski yavaş veya yükü farklı tek bir düğüm, diğer ikisini de aşağı çeker. wsrep_flow_control_paused değerini bu nedenle düzenli izliyoruz: sıfırdan belirgin şekilde uzaklaşması, kümede yetişemeyen bir düğüm olduğunun ilk göstergesidir.

Çakışma yönetimi. Her düğüm yazma kabul edebilir, ancak aynı satıra farklı düğümlerden yazıldığında işlemlerden biri sertifikasyon aşamasında geri alınır ve uygulamanın bu hatayı yakalayıp işlemi yeniden denemesi gerekir. Uygulama buna hazır değilse çok yazıcılı (multi-writer) kurulum kararlılık sorunu üretir. Çoğu üretim sisteminde yazma trafiğini tek düğümde toplayan bir kurgu öneriyoruz; erişilebilirlik aynı kalır, davranış öngörülebilir olur.

Kurulumun üçüncü kararı durum aktarımıdır: kümeye yeni katılan veya uzun süre ayrı kalan bir düğüm, tam durum aktarımı (SST) ile veriyi baştan alır. İşlem veri boyutuyla orantılı sürer ve kaynak olarak seçilen düğümü meşgul eder. Kaynak düğümün hangisi olacağını ve aktarımın ne zaman yapılacağını planlıyoruz.

Trafiğin uygulama tarafında yönlendirilmesini ProxySQL ile kuruyoruz; açık kaynak lisanslıdır ve MariaDB ile Galera kurulumlarının önünde çalışır. Topolojilerin karşılaştırması ve devralma tatbikatları için: Yüksek Erişilebilirlik ve Cluster Çözümleri · ProxySQL Destek ve Danışmanlık

Yedekleme: MariaDB’de XtraBackup çalışmaz

Fiziksel (physical) yedekleme MariaDB’de mariabackup ile yapılır. Araç, Percona XtraBackup’tan çatallanmıştır ve MariaDB sunucusuyla birlikte dağıtılır; XtraBackup’ın kendisi güncel MariaDB sürümlerinde çalışmaz.

Bu ayrıntı küçük görünür ve pahalıya mal olur. MySQL için yazılmış bir yedekleme prosedürünün MariaDB sunucusuna olduğu gibi taşındığı kurulumlarda betik hata verir; hata izlenmiyorsa yedek alınmadığı fark edilmez ve eksiklik ilk kurtarma denemesinde ortaya çıkar.

Mantıksal (logical) yedekleme ihtiyaçlarında mariadb-dump, büyük veri setlerinde paralel çalışabilen mydumper devreye girer. Belirli bir ana dönmek için binary log arşivlemesini yapılandırıyor ve PITR (Point-in-Time Recovery) yeteneğini bu şekilde sağlıyoruz.

Yedekleme mimarisinin kendisi — RTO ve RPO hedeflerinin belirlenmesi, yedek tiplerinin birlikte kurgulanması ve otomatik geri yükleme testleri — araçtan bağımsız bir disiplindir ve ayrı bir başlıkta ele alınır: Veritabanı Yedekleme ve Kurtarma

Şifreleme ve denetim kaydı çekirdekte gelir

MariaDB’nin MySQL Community Edition karşısındaki en belirgin üstünlüğü buradadır: disk üzerinde şifreleme ve denetim kaydı (audit logging) sunucuyla birlikte gelir. MySQL tarafında aynı yetenekler için Percona Server dağıtımına geçmek gerekirken, MariaDB’de ek bir dağıtım geçişi gündeme gelmez.

Şifreleme file_key_management bileşeniyle yapılandırılır ve çalışmanın ağırlığı bileşeni etkinleştirmekte değil, anahtar yönetimindedir. Şifreleme anahtarının veritabanı sunucusu üzerinde korumasız saklandığı bir kurulum, şifrelemenin amacını büyük ölçüde ortadan kaldırır. Anahtarın nerede saklanacağını, kimin erişebileceğini ve nasıl döndürüleceğini kurulumun parçası olarak tasarlıyoruz.

Denetim kaydı server_audit bileşeniyle tutulur. Kayıtların nereye yazıldığı, ne kadar süreyle saklandığı ve kimlerin erişebileceği ayrıca kurgulanır; denetim kayıtlarının kendisi de kişisel veri içerdiği için korunması gerekir. KVKK denetimlerinde istenen teknik tedbirlerin tamamı için: Veritabanı Güvenliği ve KVKK Teknik Tedbirleri

Storage engine tercihi ölçümle yapılır

MariaDB birden fazla storage engine sunar. InnoDB varsayılandır ve üretim sistemlerinin büyük bölümünde doğru seçimdir. Aria, sunucunun kendi geçici tabloları için kullanılır. ColumnStore analitik sorgular için sütun tabanlı depolama sağlar, Spider ise tabloları birden fazla sunucuya dağıtır.

Alternatif engine’leri değerlendiriyoruz, ancak ölçüm olmadan önermiyoruz. Varsayılanın dışına çıkmak operasyonel maliyeti artırır: yedekleme davranışı, kilitleme (locking) modeli ve Galera ile uyumluluk engine’e göre değişir. Galera yalnızca işlem destekli tabloları çoğaltır; işlemsel olmayan bir engine üzerinde tutulan veri cluster genelinde tutarlı kalmaz. Bu nedenle engine değişikliğini mimariyle birlikte değerlendiriyoruz.

Sürüm politikası

MariaDB, uzun destekli (LTS) sürümlerini yıllarca yamalar; kısa döngülü sürümlerin destek süresi belirgin şekilde kısadır. Üretim sistemlerinde LTS dışına çıkılmasını önermiyoruz. Kısa döngülü bir sürümde kalmak, güvenlik yaması gerektiğinde planlanmamış bir yükseltmeyi zorunlu hâle getirir.

Devraldığımız sistemlerde mevcut sürümün destek durumunu çıkarıp yükseltme takvimini planlıyoruz. Yükseltmeleri Galera kurulumlarında düğüm düğüm, kümeyi tamamen durdurmadan yürütüyoruz.

Çalışma biçimimiz

Sistemlerinize gizlilik sözleşmesi (NDA) kapsamında uzaktan bağlanıyoruz. Veritabanı kullanıcısına yalnızca yapılacak iş için gereken yetkileri tanımlıyor, uyguladığımız her değişikliği kayıt altına alıyoruz.

Bir sistemi ilk devraldığımızda önce mevcut durumu çıkarırız: sürüm ve destek durumu, Galera küme sağlığı ve akış denetimi geçmişi, yedekleme ile geri yükleme durumu, şifreleme ve denetim kaydı yapılandırması, iş yükünün sorgu profili. Öneriler bu ölçümün üzerine kurulur.

İlgili hizmetler

Aynı çalışmaları MySQL, PostgreSQL ve MongoDB için de yürütüyoruz: MySQL Destek · PostgreSQL Destek · MongoDB Destek

Sık sorulan sorular

Eski sürümlerde öyleydi, bugün değil. İki ürün uzun süredir ayrı geliştiriliyor; sorgu optimize edicileri, JSON veri tipini ele alışları, GTID uygulamaları ve cluster çözümleri farklılaştı. MySQL 8.0'dan MariaDB'ye replikasyon kurmak da desteklenmiyor. Geçişi mümkün görüyoruz, ancak sürücü değişikliği olarak değil, uyumluluk taraması ve test ortamında provası yapılan bir proje olarak planlıyoruz.

Kurulamaz. InnoDB Cluster ve Group Replication, Oracle'ın MySQL dağıtımına ait bileşenlerdir ve MariaDB'de bulunmaz. MariaDB'nin yüksek erişilebilirlik yanıtı Galera Cluster'dır ve sunucuya yerleşik olarak gelir. İki mimari benzer sonuca farklı yollardan ulaşır; Galera senkron ve sertifikasyon tabanlı çalışır, uygulamanın yazma deseni tasarımı doğrudan etkiler.

Teknik olarak yazabilirsiniz; çoğu üretim sisteminde önermiyoruz. Aynı satıra farklı düğümlerden yazıldığında çakışma sertifikasyon aşamasında tespit edilir ve işlemlerden biri geri alınır; uygulamanın bu hatayı yakalayıp işlemi yeniden denemesi gerekir. Uygulama buna hazır değilse, çok yazıcılı (multi-writer) kurulum kararlılık sorunu üretir. Yazma trafiğini tek düğümde toplayan bir kurgu, aynı erişilebilirliği çok daha öngörülebilir davranışla verir.

Güncel MariaDB sürümlerinde çalışmaz. MariaDB kendi çatallanmış aracını, mariabackup'ı sunucuyla birlikte dağıtır ve fiziksel yedekleme bu araçla yapılır. MySQL için yazılmış bir yedekleme prosedürünün MariaDB'ye olduğu gibi taşınması, sahada karşılaştığımız hatalardan biridir: yedekleme betiği hata verir ve kimse fark etmezse, eksiklik ilk kurtarma denemesinde ortaya çıkar. Devraldığımız her sistemde ilk doğruladığımız şey yedeğin gerçekten alınıp geri yüklenebildiğidir.

Gerekmez ve bu, MariaDB'nin MySQL Community Edition karşısındaki belirgin üstünlüklerinden biridir. Disk üzerinde şifreleme ve denetim kaydı MariaDB sunucusuyla birlikte gelir; ayrı bir dağıtıma geçmek gerekmez. Çalışma, bileşenleri etkinleştirmekten çok anahtar yönetiminin doğru kurgulanmasına odaklanır: şifreleme anahtarının veritabanı sunucusu üzerinde korumasız saklandığı bir kurulum, şifrelemenin amacını büyük ölçüde ortadan kaldırır.

Üretim sistemlerinde uzun destekli (LTS) sürümlerin dışına çıkılmasını önermiyoruz. MariaDB, LTS olarak işaretlenen sürümleri yıllarca yamalarken kısa döngülü sürümlerin destek süresi belirgin şekilde kısadır; kısa döngülü bir sürümde kalmak, planlanmamış bir yükseltmeyi güvenlik yaması gerektiğinde zorunlu hâle getirir. Mevcut sürümünüzün destek durumunu çıkarıp yükseltme takvimini birlikte planlıyoruz.

MariaDB destek talebinizi iletin