Migracja z MySQL Enterprise do MariaDB 10.3

Chociaż ma to samo dziedzictwo co MySQL, MariaDB jest inną bazą danych. Z biegiem lat, gdy pojawiły się nowe wersje MySQL i MariaDB, oba projekty różniły się na dwóch różnych platformach RDBMS.

MariaDB staje się główną dystrybucją baz danych na wielu platformach Linux i obecnie zyskuje na popularności. Jednocześnie staje się bardzo atrakcyjnym systemem bazodanowym dla wielu korporacji. Otrzymuje funkcje zbliżone do potrzeb przedsiębiorstwa, takie jak szyfrowanie, kopie zapasowe na gorąco lub zgodność z zastrzeżonymi bazami danych.

Ale jak nowe funkcje wpływają na zgodność MariaDB z MySQL? Czy nadal jest to zamiennik dla MySQL? Jak najnowsze zmiany wzmacniają proces migracji? Postaramy się odpowiedzieć na to w tym artykule.

Co musisz wiedzieć przed aktualizacją

MariaDB i MySQL znacznie różnią się od siebie w ciągu ostatnich dwóch lat, zwłaszcza wraz z pojawieniem się ich najnowszych wersji:MySQL 8.0, MariaDB 10.3 i MariaDB 10.4 RC (niedawno omawialiśmy nowe funkcje MariaDB 10.4 RC, więc jeśli chcesz czytaj więcej o nowościach w 10.4, sprawdź dwa blogi mojego kolegi Krzysztofa, Co nowego w MariaDB 10.4 i drugi o Co nowego w MariaDB Cluster 10.4).

Wraz z wydaniem MariaDB 10.3, MariaDB zaskoczyła wielu, ponieważ nie jest już bezpośrednim zamiennikiem dla MySQL. MariaDB nie łączy już nowych funkcji MySQL z MariaDB noir rozwiązując błędy MySQL. Niemniej jednak wersja 10.3 staje się teraz prawdziwą alternatywą dla Oracle MySQL Enterprise, a także innych zastrzeżonych baz danych korporacyjnych, takich jak Oracle 12c (MSSQL w wersji 10.4).

Wstępna kontrola i ograniczenia

Migracja to złożony proces bez względu na wersję, do której się aktualizujesz. Planując to, należy pamiętać o kilku rzeczach, takich jak istotne zmiany między wersjami RDBMS, a także szczegółowe testy, które muszą poprowadzić każdy proces aktualizacji. Jest to szczególnie ważne, jeśli chcesz zachować dostępność na czas aktualizacji.

Aktualizacja do nowej wersji głównej wiąże się z ryzykiem i ważne jest, aby dokładnie zaplanować cały proces. W tym dokumencie przyjrzymy się ważnym nowym zmianom w wersji 10.3 (i nadchodzącej 10.4) i pokażemy, jak zaplanować proces testowania.

Aby zminimalizować ryzyko, przyjrzyjmy się różnicom i ograniczeniom platform.

Począwszy od konfiguracji, niektóre parametry mają różne wartości domyślne. MariaDB udostępnia macierz różnic parametrów. Można go znaleźć tutaj.

W MySQL 8.0 caching_sha2_password jest domyślną wtyczką uwierzytelniającą. To ulepszenie powinno poprawić bezpieczeństwo dzięki zastosowaniu algorytmu SHA-256. MySQL ma tę wtyczkę domyślnie włączoną, podczas gdy MariaDB nie. Chociaż istnieje już żądanie funkcji otwarte w MariaDB MDEV-9804. MariaDB oferuje zamiast tego wtyczkę ed25519, która wydaje się być dobrą alternatywą dla starej metody uwierzytelniania.

Obsługa MariaDB dla szyfrowania tabel i obszarów tabel została dodana w wersji 10.1.3. Ponieważ Twoje tabele są szyfrowane, kradzież Twoich danych jest prawie niemożliwa. Ten rodzaj szyfrowania umożliwia również Twojej organizacji zachowanie zgodności z przepisami rządowymi, takimi jak RODO.

MariaDB obsługuje pule wątków połączeń, które są najbardziej efektywne w sytuacjach, gdy zapytania są stosunkowo krótkie, a obciążenie jest powiązane z procesorem. W wersji Community MySQL liczba wątków jest statyczna, co ogranicza elastyczność w takich sytuacjach. Plan korporacyjny MySQL obejmuje możliwości puli wątków.

MySQL 8.0 zawiera schemat sys, zestaw obiektów, który pomaga administratorom baz danych i inżynierom oprogramowania interpretować dane zebrane przez schemat wydajności. Obiekty schematu Sys mogą być używane do optymalizacji i diagnostyki przypadków użycia. MariaDB nie zawiera tego ulepszenia.

Kolejny to niewidoczne kolumny. Niewidoczne kolumny dają elastyczność dodawania kolumn do istniejących tabel bez obawy o uszkodzenie aplikacji. Ta funkcja nie jest dostępna w MySQL. Umożliwia tworzenie kolumn, które nie są wymienione w wynikach instrukcji SELECT *, ani nie muszą mieć przypisanej wartości w instrukcji INSERT, gdy ich nazwa nie jest wymieniona w instrukcji.

MariaDB zdecydowała się nie wdrażać natywnej obsługi JSON (jedna z głównych funkcji MySQL 5.7 i 8.0), ponieważ twierdzą, że nie jest to część standardu SQL. Zamiast tego, aby obsługiwać replikację z MySQL, zdefiniowali tylko alias dla JSON, który w rzeczywistości jest kolumną LONGTEXT. Aby zapewnić wstawienie prawidłowego dokumentu JSON, funkcji JSON_VALID można użyć jako ograniczenia CHECK (domyślne dla MariaDB 10.4.3). MariaDB nie może uzyskać bezpośredniego dostępu do formatu MySQL JSON.

Oracle automatyzuje wiele zadań dzięki MySQL Shell. Oprócz SQL, MySQL Shell oferuje również możliwości tworzenia skryptów dla JavaScript i Python.

Proces migracji za pomocą mysqldump

Gdy znamy nasze ograniczenia, proces instalacji jest dość prosty. Jest to w dużej mierze związane ze standardową instalacją i importem za pomocą mysqldump. Narzędzie do tworzenia kopii zapasowych MySQL Enterprise nie jest kompatybilne z MariaDB, więc zalecanym sposobem jest użycie mysqldump. Oto przykładowy proces wykonywany na Centos 7 i MariaDB 10.3.

Utwórz zrzut na serwerze MySQL Enterprise

$ mysqldump --routines --events --triggers --single-transaction db1 > export_db1.sql

Wyczyść indeks pamięci podręcznej mniam

sudo yum makecache fast

Zainstaluj MariaDB 10.3

sudo yum -y install MariaDB-server MariaDB-client

Uruchom usługę MariaDB.

sudo systemctl start mariadb
sudo systemctl enable mariadb

Zabezpiecz MariaDB, uruchamiając mysql_secure_installation.

# mysql_secure_installation 

NOTE: RUNNING ALL PARTS OF THIS SCRIPT IS RECOMMENDED FOR ALL MariaDB
      SERVERS IN PRODUCTION USE!  PLEASE READ EACH STEP CAREFULLY!

In order to log into MariaDB to secure it, we'll need the current
password for the root user.  If you've just installed MariaDB, and
you haven't set the root password yet, the password will be blank,
so you should just press enter here.

Enter current password for root (enter for none): 
OK, successfully used password, moving on...

Setting the root password ensures that nobody can log into the MariaDB
root user without the proper authorisation.

Set root password? [Y/n] y
New password: 
Re-enter new password: 
Password updated successfully!
Reloading privilege tables..
 ... Success!


By default, a MariaDB installation has an anonymous user, allowing anyone
to log into MariaDB without having to have a user account created for
them.  This is intended only for testing, and to make the installation
go a bit smoother.  You should remove them before moving into a
production environment.

Remove anonymous users? [Y/n] y
 ... Success!

Normally, root should only be allowed to connect from 'localhost'.  This
ensures that someone cannot guess at the root password from the network.

Disallow root login remotely? [Y/n] y
 ... Success!

By default, MariaDB comes with a database named 'test' that anyone can
access.  This is also intended only for testing, and should be removed
before moving into a production environment.

Remove test database and access to it? [Y/n] y
 - Dropping test database...
 ... Success!
 - Removing privileges on test database...
 ... Success!

Reloading the privilege tables will ensure that all changes made so far
will take effect immediately.

Reload privilege tables now? [Y/n] y
 ... Success!

Cleaning up...

All done!  If you've completed all of the above steps, your MariaDB
installation should now be secure.
Thanks for using MariaDB!

Importuj zrzut

Mysql -uroot -p
> tee import.log
> source export_db1.sql
Review the import log.

$vi import.log

Aby wdrożyć środowisko, możesz również użyć ClusterControl, który ma opcję wdrożenia od zera.

ClusterControl może być również używany do konfigurowania replikacji lub importowania kopii zapasowej z MySQL Enterprise Edition.

Proces migracji przy użyciu replikacji

Innym podejściem do migracji pomiędzy MySQL Enterprise i MariaDB jest użycie procesu replikacji. Wersje MariaDB umożliwiają replikację do nich z baz danych MySQL - co oznacza, że ​​możesz łatwo migrować bazy danych MySQL do MariaDB. Wersje MySQL Enterprise nie pozwalają na replikację z serwerów MariaDB, więc jest to droga jednokierunkowa.

Oto kilka ogólnych zasad wskazanych przez MariaDB.

• Replikacja z MySQL 5.5 do MariaDB 5.5+ powinna po prostu działać. Chcesz, aby MariaDB była w tej samej lub wyższej wersji niż Twój serwer MySQL.
• W przypadku korzystania z MariaDB 10.2+ jako urządzenia podrzędnego może być konieczne ustawienie binlog_checksum na BRAK.
• Replikacja z MySQL 5.6 bez GTID do MariaDB 10+ powinna działać.
• Replikacja z MySQL 5.6 z GTID, binlog_rows_query_log_events i ignorowanymi zdarzeniami działa od wersji MariaDB 10.0.22 i MariaDB 10.1.8. W takim przypadku MariaDB usunie identyfikatory GTID MySQL i inne niepotrzebne zdarzenia, a zamiast tego doda własne identyfikatory GTID.

Nawet jeśli nie planujesz używać replikacji w procesie migracji/przełączania, dobrym sposobem na zbudowanie zaufania jest replikacja serwera produkcyjnego w testowej piaskownicy, a następnie ćwiczenie na niej.

Mamy nadzieję, że ten wprowadzający wpis na blogu pomógł Ci zrozumieć proces oceny i implementacji MySQL Enterprise Migration to MariaDB.