MariaDB 12.0: funkcje, ryzyko związane z aktualizacją i strategia hostingu

Prawidłowe sklasyfikowanie MariaDB 12.0

Określenie „MariaDB 12“ nie odnosi się do jednolitej, stale aktualizowanej wersji produktu. W przypadku konkretnych informacji technicznych należy odwołać się do serii Rolling MariaDB 12.0 chodzi o to. W ramach tej serii poszczególne wydania charakteryzują się różnym stopniem dojrzałości: wersja 12.0.0 ukazała się 26 marca 2025 r. jako wersja zapoznawcza, wersja 12.0.1 5 czerwca 2025 r. jako wersja Release Candidate, a wersja 12.0.2 7 sierpnia 2025 r. jako stabilna wersja GA.

Wersje Preview i Release Candidate służą do testowania i nie należy ich utożsamiać ze stabilną wersją docelową platformy. Natomiast fakt, że wersja 12.0.2 jest udokumentowana jako stabilna (Stable) lub GA, dokładnie opisuje stopień dojrzałości właśnie tej wersji. Nie oznacza to jednak ani tego, że każda instalacja powinna zostać natychmiast zaktualizowana, ani tego, że późniejsze wersje będą automatycznie posiadały te same właściwości, pakiety lub ograniczenia eksploatacyjne.

Również późniejsze gałęzie, takie jak 12.1, 12.2 czy 12.3, należy rozpatrywać oddzielnie. Funkcje, poprawki błędów lub zmienione wartości domyślne z tych serii nie stanowią dowodu na MariaDB 12.0. Dotyczy to również gałęzi rozwojowych: ogłoszenia lub dokumentacja w tych gałęziach nie zastępują informacji o opublikowanym stanie serwera społecznościowego.

Przed wdrożeniem platforma wymaga zatem ponownego porównania faktycznie przewidzianego stanu pakietów. Należy w szczególności sprawdzić dostępną serię serwerów, kompatybilność pakietów klienckich i dodatkowych, obsługę przez używaną wersję systemu operacyjnego oraz aktualną klasyfikację wydania. Zawartość repozytorium i pakiety dystrybucyjne mogą różnić się od ogólnej nazwy produktu.

Różnica między modelem „rolling release” a LTS

W przypadku platform hostingowych istotny jest nie tylko numer wersji, ale także leżąca u ich podstaw Model wydania. MariaDB rozróżnia wersje innowacyjne od wersji LTS. Wersje innowacyjne wprowadzają nowe funkcje w krótkich odstępach czasu i zazwyczaj po osiągnięciu statusu GA przechodzą do kolejnej serii rollingowej. Natomiast wersje LTS są, według producenta, utrzymywane przez trzy lata od momentu osiągnięcia statusu GA.

Stabilna wersja GA odpowiada zatem jedynie na pytanie, czy ta konkretna wersja została wydana jako stabilna. Nie daje ona ogólnej odpowiedzi na to, jak długo będą dostępne poprawki bezpieczeństwa, czy dystrybutor będzie nadal dostarczał pakiety ani czy obecni klienci mogą pozostać na tej serii bez konieczności migracji. Kwestie te zależą od umowy, dystrybucji oraz aktualnego zestawienia wydań.

Seria innowacji może być uzasadniona, gdy platforma chce wcześnie wdrożyć funkcję, na którą istnieje wyraźne zapotrzebowanie, i ma możliwość przetestowania w izolacji odpowiednich aplikacji, łączników oraz procesów operacyjnych. W tym celu zespoły muszą zaplanować szybkie kontynuowanie przewidzianej ścieżki aktualizacji. Szczególnie w przypadku rozwiązań wielodostępnych zwiększa to nakład pracy związany z zatwierdzaniem, komunikacją i procedurami awaryjnymi.

A Stan docelowy LTS Rozwiązanie to lepiej sprawdza się w przypadku standardowych platform z wieloma klasycznymi aplikacjami, gdy planowane okna serwisowe i długotrwała stabilność oprogramowania są ważniejsze niż pojedyncze nowe funkcje. Nie jest to jednak zasada wykluczająca wprowadzanie innowacji: decydujące znaczenie ma to, czy korzyści płynące z danej funkcji uzasadniają dodatkowe testy i spodziewaną zmianę na kolejną serię.

Wybór powinien zatem uwzględniać co najmniej wymagania funkcjonalne, aktualny stan pakietów i wsparcia technicznego, sprawdzoną kompatybilność aplikacji, możliwość przywrócenia danych oraz nakłady kadrowe związane z eksploatacją. W przypadku nowej instalacji nie wystarczy uznać „MariaDB 12“ za najnowszą wersję. Platforma świadomie dokonuje wyboru między krótkoterminowym wykorzystaniem funkcji a długoterminową standaryzacją stanu bazy danych.

Ocena nowych funkcji pod kątem ich ograniczeń

Uzupełnienie dotyczące MariaDB 12.0 Wskazówki dotyczące optymalizatora w celu bardziej ukierunkowanego wpływu na plany wykonania, na przykład w odniesieniu do kolejności połączeń, optymalizacji zakresów lub określonych algorytmów połączeń. Rozszerzenia dotyczą również elementów indeksu posortowanych malejąco w przypadku Loose Index Scan i Index Condition Pushdown. W przypadku hostingu jest to przede wszystkim narzędzie diagnostyczne służące do analizy poszczególnych problematycznych zapytań, a nie substytut odpowiednich indeksów, poprawnych warunków połączeń oraz aktualnych statystyk tabel.

Wskazówka może ograniczyć niepożądany scenariusz, ale w miarę wzrostu ilości danych lub zmiany statystyk może sama w sobie przynieść negatywne skutki. Dlatego powinna ona stanowić część powtarzalnej analizy danej aplikacji, a nie być stosowana jako ogólne wytyczne w serwer bazy danych. W przypadku typowych baz danych systemów CMS i sklepów internetowych sama dostępność takich wskazówek nie stanowi wystarczającego powodu do aktualizacji MariaDB.

Podczas audytu wtyczka audytowa w wersji 12.0 rejestruje dodatkowo host i port połączeń przychodzących, a także używaną wersję TLS. W przypadku dostępu za serwerami proxy, NAT lub modułami równoważenia obciążenia może to poprawić identyfikację kryminalistyczną. Korzyść ta wynika jednak dopiero z centralnego, zabezpieczonego przed nieuprawnionym dostępem gromadzenia logów oraz ustalonych zasad przechowywania danych; dodatkowe dane logów muszą być uwzględnione w planowaniu pojemności i ochrony danych.

W zakresie szyfrowania dostępne jest wsparcie dla algorytmu SHA-2 w file_key_management.so oraz ssl_passphrase Moduły gotowe. Środowiska replikacji zyskują opcje dotyczące tabel tymczasowych oraz zmienną służącą do obsługi zdarzeń o własnym identyfikatorze serwera. Ponadto wersja 12.0 wprowadza między innymi SYS_REFCURSOR, limit kursorów na sesję oraz funkcje GIS, takie jak walidacja, uproszczenie i konwersja geohash. Narzędzia te są przydatne wyłącznie w odpowiednich zastosowaniach i topologiach.

Serwer MariaDB, MaxScale i Galera pozostają odrębnymi komponentami: MaxScale ma własne wersje i konfiguracje, a zmiany związane z Galerą dotyczą wyłącznie klastrów. Podobnie kompatybilność z MySQL nie oznacza możliwości zamiany bez uprzedniej weryfikacji. MariaDB wykorzystuje własny model GTID i nie obsługuje na przykład funkcji MySQL SET PERSIST. Nowe funkcje GIS mogą być pomocne w aplikacjach do obsługi danych geograficznych opartych na MySQL 8, jednak w przypadku zwykłych internetowych baz danych zazwyczaj nie stanowią one powodu do aktualizacji.

Porównanie statusu wydania i funkcji

Dla działania platformy decydujące znaczenie ma konkretny status w ramach serii. MariaDB 12.0.0 była wersją podglądową, 12.0.1 – wersją kandydacką, a dopiero 12.0.2 została udokumentowana jako wersja stabilna (GA). Statusy te wskazują na różne poziomy dojrzałości; nie stanowią one jednak informacji o tym, czy dana seria nadaje się do konkretnego wdrożenia hostingowego, systemu operacyjnego lub umowy serwisowej.

Nowe funkcje są przydatne przede wszystkim wtedy, gdy rozwiązują konkretny problem operacyjny. Wskazówki dotyczące optymalizatora mogą na przykład ograniczyć niepożądany plan wykonania pojedynczego złożonego zapytania. Nie zastępują one jednak odpowiednich indeksów, poprawnych warunków połączeń ani aktualnych statystyk i nie powinny być stosowane jako ogólne wytyczne dla aplikacji klientów.

Dodatkowe pola audytu mogą rejestrować host, port oraz wersję protokołu TLS używaną w połączeniu przychodzącym. Opcja klucza ssl_passphrase Natomiast rozszerzone funkcje GIS lub kursora nie uzasadniają ogólnej zmiany wersji. Ich korzyści ujawniają się jedynie w przypadku aplikacji, których architektura, model danych i wymogi bezpieczeństwa faktycznie wymagają tych możliwości.

Kontrolowane przygotowanie aktualizacji MariaDB

Aktualizacja MariaDB w ramach hostingu zarządzanego lub współdzielonego rozpoczyna się od inwentaryzacji: należy zidentyfikować instancje, bazy danych, łączniki, wtyczki, pliki konfiguracyjne, ścieżki replikacji oraz aplikacje, których dotyczy aktualizacja. Następnie tworzy się środowisko testowe, które odzwierciedla dane produkcyjne i konfigurację wyłącznie zgodnie z dopuszczalnymi wymogami bezpieczeństwa. Pozwala to wykryć problemy związane z uruchomieniem oraz nieprawidłowości w kodzie SQL, zanim dotkną one wielu klientów.

Przed każdym ograniczonym wdrożeniem konieczne jest wykonanie pełnej kopii zapasowej oraz opracowanie udokumentowanej procedury przywracania danych. Nie chodzi tylko o to, aby pliki kopii zapasowej były dostępne: osoby odpowiedzialne muszą sprawdzić, czy na ich podstawie można odtworzyć spójny stan danych, który będzie można wykorzystać w aplikacjach. Następnie sprawdzają logowania, operacje zapisu, zadania w tle oraz typowe ścieżki klientów jako Regresja aplikacji. Konkretny sposób postępowania zależy od zastosowanej metody zabezpieczeń oraz architektury platformy.

Plan awaryjny określa, kto decyduje, które stany danych są miarodajne oraz w jaki sposób aplikacje powracają do poprzedniego spójnego stanu w przypadku przerwania procesu. Jest to standardowa praktyka operacyjna, a nie cecha charakterystyczna konkretnej wersji MariaDB. Replikację, monitorowanie i przełączanie awaryjne należy zatem sprawdzać w danej topologii stagingowej, zamiast wyciągać wnioski na temat ich działania na podstawie pomyślnej aktualizacji pojedynczej instancji.

W wersji MariaDB 12.0 usunięto zmienne systemowe big_tables, large_page_size oraz storage_engine. Istniejące wpisy należy zatem zamieścić w my.cnf i we wszystkich powiązanych fragmentach konfiguracji, a następnie poddane ocenie pod kątem stanu docelowego. Operacja czyszczenia musi zostać przeprowadzona przed aktualizacją pakietu; w przypadku large_page_size Należy ponadto rozróżnić między usuniętą zmienną MariaDB a niezależną od niej konfiguracją HugePages w systemie operacyjnym.

Również planowanie pakietów zasługuje na osobny etap: jedno repozytorium może zawierać kilka wersji MariaDB, a powiązane pakiety serwerowe, klienckie, współdzielone i wspólne powinny mieć tę samą wersję. Wersja systemu operacyjnego i źródła pakietów stanowią w tym przypadku część procesu zatwierdzania. Jeśli chodzi o zależności na poziomie hosta, artykuł na temat istotne zmiany dotyczące serwerów hostingowych z jądrem Linux 6.x dodatkowy kontekst; nie zastępuje on jednak kontroli przygotowawczej specyficznej dla danej bazy danych.

Bezpieczne konfigurowanie przypadków szczególnych

W przypadku niestabilnych zapytań raportowych diagnostykę należy rozpocząć od analizy planów wykonania, indeksów, warunków połączeń oraz statystyk tabel. Dopiero gdy niepożądany plan zostanie w sposób powtarzalny zidentyfikowany, wskazówka dla optymalizatora może stanowić ukierunkowane ograniczenie. Wskazówka ta odnosi się do danego zapytania i powinna zostać uwzględniona w udokumentowanej analizie, ponieważ wzrost ilości danych lub zmiana statystyk mogą w późniejszym czasie wpłynąć na jej skuteczność.

Do przeprowadzenia analizy stanu bez ryzyka nadają się zapytania odczytowe. Należy je wykonywać przy użyciu konta posiadającego wyłącznie uprawnienia niezbędne do tego celu; nie zmieniają one ani danych, ani uprawnień, ani konfiguracji serwera. Wyniki wskazują faktycznie podłączony serwer bazy danych i pomagają zweryfikować założenia zawarte w dokumentacji wdrożeniowej.

SELECT VERSION();
SHOW VARIABLES LIKE 'max_open_cursors';
SHOW VARIABLES LIKE 'create_tmp_table_binlog_formats';

W architekturze proxy SET SESSION AUTHORIZATION nie jest to funkcja zwiększająca wygodę, lecz ingerencja w model bezpieczeństwa. Zmiana sesji wymaga uprawnienia SET USER i nie jest dostępna w ramach transakcji, przygotowanych instrukcji ani procedur przechowywanych.

Obsługiwane wersje MaxScale mogą korzystać z danych dostępowych usługi do połączenia z serwerem zaplecza, a następnie przełączać się na tożsamość klienta. Wymaga to serwera zaplecza MariaDB w wersji 12 lub nowszej oraz uprawnienia SET USER wymagane dla konta serwisowego. Jednak sama obecność backendu MariaDB 12.0 nie gwarantuje tej możliwości: przed wdrożeniem należy sprawdzić konkretną kombinację serwera MariaDB, wersji MaxScale i konfiguracji.

Ustawienie MaxScale use_service_credentials W odpowiednich wersjach określa, czy MaxScale najpierw loguje się do serwera zaplecza przy użyciu danych dostępowych zapisanych w usłudze, a następnie przechodzi na tożsamość klienta. Konto serwisu nie może posiadać żadnych dodatkowych uprawnień administracyjnych poza tymi, które są technicznie niezbędne. Audyt oraz udokumentowane wyłączenie awaryjne muszą być dostosowane do modelu połączeń i puli.

Topologie replikacji i Galera wymagają osobnej ścieżki testowej dla przełączania awaryjnego, ponownego dołączania i odzyskiwania danych. Opcji dotyczących tabel tymczasowych lub postępowania w przypadku identycznych identyfikatorów serwerów nie wolno zmieniać bez zrozumienia formatu dziennika binarnego, identyfikatora serwera oraz ścieżki powrotnej. Optymalizacja Galera nie stanowi ponadto ogólnej gwarancji wydajności klastra, ponieważ decydujące znaczenie mają profil obciążenia i opóźnienia sieciowe.

Każdy, kto dokonuje oceny tabel wewnętrznych, struktur tymczasowych lub silników przechowywania danych w danym środowisku, powinien rozpatrywać rolę danego silnika oddzielnie od migracji wersji. Artykuł na temat Silnik bazy danych MariaDB Aria w usłudze hostingowej klasyfikuje tego typu kwestie związane z wdrożeniem. Jednak dla podjęcia decyzji o aktualizacji decydujące znaczenie ma to, czy konkretna aplikacja i jej procesy operacyjne będą działać w sposób powtarzalny w środowisku docelowym.

Zabezpieczenie zmiany sesji i audytu

SET SESSION AUTHORIZATION stanowi element składowy świadomie zaprojektowanych architektur połączeń, a nie tylko ułatwienie w administrowaniu. Polecenie to pozwala uprawnionemu kontu działać w ramach bieżącej sesji pod tożsamością innego użytkownika. Warunkiem jest posiadanie uprawnienia SET USER. W ten sposób odpowiedzialność za rejestrację i weryfikację tożsamości zostaje częściowo przeniesiona z poszczególnych połączeń klientów na kontrolowany element platformy.

W przypadku serwera proxy taki schemat może być sensowny, jednak serwer MariaDB i MaxScale pozostają odrębnymi produktami z własnym systemem numeracji wersji. Tylko wersje MaxScale, które obsługują korzystanie z danych dostępowych usługi z następującą po tym zmianą tożsamości, mogą zapewnić taki przebieg procesu. Backend MariaDB 12.0 nie rozszerza automatycznie starszej lub inaczej skonfigurowanej gałęzi MaxScale o tę funkcję.

W obsługiwanej kombinacji serwer proxy loguje się na serwerze MariaDB przy użyciu konta serwisowego, a następnie przełącza się na żądaną tożsamość użytkownika. Ustawienie use_service_credentials wymaga w tym celu serwera zaplecza MariaDB w wersji 12 lub nowszej, a także SET USER dla konta serwisowego. Przed wdrożeniem należy zatem wspólnie sprawdzić konkretne wersje MariaDB i MaxScale, które będą używane, konfigurację oraz przewidziany sposób uwierzytelniania.

Konto serwisowe służy do Zmiana tożsamości ma kluczowe znaczenie dla bezpieczeństwa. Ten przywilej SET USER nie przyznaje mu automatycznie dowolnych globalnych uprawnień administracyjnych; ponadto może on otrzymać jedynie uprawnienia niezbędne z technicznego punktu widzenia. W przypadku zmiany sesji można między innymi ominąć blokadę konta, wygaśnięcie hasła, uwierzytelnianie oraz weryfikację REQUIRE-SSL konta docelowego. Zmiana ta nie jest również dostępna w ramach transakcji, przygotowanych instrukcji (Prepared Statements) ani procedur przechowywanych (Stored Procedures).

W przypadku hostingu obsługującego wielu klientów oznacza to, że konta klientów pozostają logicznie oddzielone, a dopuszczalny zakres zmian jest udokumentowany i ograniczony. Ponadto platforma musi dysponować mechanizmem wyłączania awaryjnego, na przykład poprzez zablokowanie konta serwisowego lub usunięcie danej ścieżki połączenia zgodnie z ustaloną procedurą postępowania w przypadku incydentów. Wybór odpowiedniego środka należy dostosować do puli połączeń, istniejących sesji oraz wpływu na innych klientów.

Wtyczka Audit w MariaDB 12.0 uzupełnia informacje o połączeniach przychodzących o dane dotyczące hosta i portu, a także używaną wersję protokołu TLS. Dane te pomagają lepiej zidentyfikować połączenia pochodzące zza NAT, urządzeń równoważących obciążenie lub serwerów proxy. Nie zastępują one jednak niezawodnej identyfikacji, jeśli system znajdujący się przed serwerem bazy danych modyfikuje informacje o źródle lub przekazuje do serwera bazy danych wyłącznie swój własny adres.

Wchodzi w życie Audyt przede wszystkim w ramach procesu operacyjnego: logi powinny być gromadzone centralnie, chronione przed nieuprawnionymi zmianami oraz zarządzane zgodnie z ustalonym okresem przechowywania. Należy rozdzielić uprawnienia dostępu do przeglądania i eksportu, podobnie jak zakres odpowiedzialności za generowanie alarmów i analizę zdarzeń. Bez przeprowadzenia pomiarów nie da się na podstawie samej wersji oprogramowania stwierdzić, czy dodatkowe dane protokołów mają zauważalny wpływ na pojemność lub wydajność konkretnej platformy.

W przypadku incydentu bezpieczeństwa operatorzy powinni być w stanie ustalić, jaką tożsamość ustawił serwer proxy, przez które połączenie nawiązano sesję oraz jakie dane audytowe są z tym związane. Regularne, udokumentowane kontrole wyłączania serwera oraz dostępności logów są ważniejsze niż jak najszersze protokołowanie. W szczególności log audytowy nie może zastępować koncepcji uprawnień, szyfrowania transmisji ani bezpiecznego zarządzania hasłami.

Monitorowanie działania po aktualizacji

Po aktualizacji MariaDB rozpoczyna się faza obserwacyjna – nie następuje automatyczna optymalizacja. Najpierw należy ustalić, czy Uruchomienie serwera wystąpi błąd, aplikacja nie będzie mogła nawiązać połączenia lub ścieżka replikacji ulegnie zmianie. Te sytuacje błędowe mają różne przyczyny i wymagają zastosowania odrębnych rozwiązań, a nie wprowadzania ogólnych zmian w konfiguracji.

Błędy uruchamiania są lokalizowane na podstawie dziennika błędów serwera oraz wersjonowanego wykazu faktycznie załadowanych plików konfiguracyjnych. Na przykład w MariaDB 12.0 big_tables oraz storage_engine usunięto. Takie wpisy nie mogą pozostać bez zmian w my.cnf lub w powiązanych fragmentach konfiguracji; udokumentowany opis zmiennej oraz komunikat początkowy wskazują, które konkretne ustawienie jest objęte zmianą.

W przypadku łączników i wtyczek należy wspólnie zarejestrować zainstalowane pakiety, załadowane wersje modułów oraz komunikat o błędzie aplikacji. Sam wybór repozytorium nie gwarantuje zgodności instalacji: w przypadku konkretnej wersji serwera należy zaplanować pakiety serwerowe, klienckie, współdzielone i wspólne o tej samej wersji. Dostępne nazwy i wersje zależą od używanego repozytorium i systemu operacyjnego.

Błędy aplikacji najlepiej analizować na podstawie powtarzalnego, możliwie niewielkiego zapytania SQL oraz powiązanych logów klienta lub modułu łączącego. Analizę stanu przy odczycie można przeprowadzić za pomocą SELECT VERSION(); rozpocząć. Wynik pozwala zidentyfikować serwer bazy danych, który udzielił odpowiedzi, ale nie potwierdza ani zgodności ORM, ani prawidłowego działania konfiguracji aplikacji.

W przypadku replikacji w dokumentacji diagnostycznej należy uwzględnić udokumentowany stan replikacji, format dziennika binarnego, identyfikatory serwerów oraz zdarzenia związane z przełączeniem awaryjnym i ponownym dołączeniem. Tabele tymczasowe, topologię oraz zmiany w opcjach replikacji należy sprawdzić oddzielnie. Pomyślny wynik lokalnego testu zapisu nie wystarcza do potwierdzenia spójności i oczekiwanego zachowania na wszystkich zaangażowanych instancjach.

Dzienniki serwerów i audytowe, spis konfiguracji, sprawdzanie wersji oraz powtarzalne testy zapytań składają się łącznie na logiczny ciąg błędów. Ułatwia to również podjęcie decyzji, czy należy uruchomić plan awaryjny. Wyższy numer wersji nie oznacza ani konkretnego wpływu na wydajność, ani uniwersalnego dostrajania; zmiany parametrów pamięci, optymalizatora lub replikacji wymagają konkretnej hipotezy i weryfikowalnego efektu.

Strategiczne rozstrzygnięcie wyniku końcowego

Odpowiedni stan docelowy zależy od przeznaczenia platformy i modelu operacyjnego, a nie od ogólnej nazwy „MariaDB 12”. W przypadku klasycznych baz danych systemów CMS, sklepów internetowych i aplikacji internetowych bezpieczeństwo aktualizacji, wyraźne oddzielenie klientów oraz niezawodna ścieżka przywracania danych mają zazwyczaj pierwszeństwo przed poszczególnymi nowymi funkcjami SQL. Nowe funkcje lub procedury GIS nie stanowią samodzielnego powodu do migracji, jeśli aplikacje z nich nie korzystają.

Złożone aplikacje raportowe mogą czerpać korzyści z podpowiedzi optymalizatora, jeśli analiza wyraźnie wyklucza niepożądany plan wykonania. Wcześniej należy sprawdzić indeksy, warunki połączeń, rozkład danych i statystyki. Wskazówka stanowi celowe powiązanie z decyzją dotyczącą planu i może stać się nieodpowiednia w wyniku wzrostu ilości danych lub zmiany statystyk; dlatego też należy ją uwzględnić w dokumentacji aplikacji wraz z zapytaniem, uzasadnieniem i kryterium cofnięcia.

Środowiska proxy i klastrów wymagają osobnej ścieżki testowej. W przypadku proxy dotyczy to w szczególności modelu uprawnień konta usługowego, zmian sesji oraz możliwości audytu. W przypadku replikacji lub Galery obejmuje to przełączanie awaryjne, ponowne dołączanie, przywracanie oraz zachowanie tabel tymczasowych. Pomyślna aktualizacja pojedynczej instancji nie gwarantuje, że procesy te działają poprawnie w całej topologii.

Die Strategia wprowadzania na rynek należy oddzielnie oceniać wersje innowacyjne i wersje LTS. MariaDB opisuje wersje innowacyjne jako wersje typu „rolling release”, które po osiągnięciu statusu GA zazwyczaj nie są na bieżąco aktualizowane o poprawki; przewidziana ścieżka prowadzi do kolejnej serii „rolling release”. Wersje LTS są natomiast obsługiwane przez trzy lata od daty GA. Nie oznacza to jednak ogólnego zobowiązania do zapewnienia wsparcia w postaci pakietów lub umów dla konkretnego środowiska hostingowego.

Przed podjęciem decyzji należy zatem wspólnie ocenić zawartość pakietów i poziom wsparcia danej dystrybucji, sprawdzoną kompatybilność aplikacji, udokumentowaną procedurę przywracania danych, model bezpieczeństwa oraz bieżące koszty eksploatacji. MariaDB i MySQL, pomimo wielu wspólnych wzorców SQL, nie są zamienne: MariaDB wykorzystuje własny model GTID i nie obsługuje na przykład funkcji MySQL SET PERSIST. Należy zatem zweryfikować założenia dotyczące migracji ze środowiska MySQL.

W przypadku serii 12.0 wersja 12.0.2 została udokumentowana jako stabilna wersja GA, podczas gdy wersje 12.0.0 były wersjami zapoznawczymi, a 12.0.1 – kandydatami do wydania. Ta klasyfikacja odzwierciedla ówczesny stopień dojrzałości, nie zastępuje jednak aktualnej decyzji o wydaniu. Bezpośrednio przed wdrożeniem lub publikacją operatorzy muszą ponownie zweryfikować oferowaną wersję pakietu, obsługę systemu operacyjnego oraz aktualną klasyfikację wydania w oparciu o informacje producenta.

Decydujące znaczenie ma zatem konkretna, sprawdzona wersja platformy wraz z jej zależnościami i zasadami działania. Kontrolowane wdrożenie jest uzasadnione, jeśli kompatybilność, plan awaryjny i podział obowiązków zostały w sposób weryfikowalny przygotowane. W przypadku braku tych warunków sama nazwa MariaDB 12 nie stanowi argumentu przemawiającego za podjęciem ryzyka w ramach hostingu współdzielonego lub w środowisku baz danych o znaczeniu krytycznym dla działalności.