Мигриране от MySQL Enterprise към MariaDB 10.3

Въпреки че споделя същото наследство с MySQL, MariaDB е различна база данни. През годините, когато бяха пуснати нови версии на MySQL и MariaDB, и двата проекта се различаваха в две различни RDBMS платформи.

MariaDB се превръща в основната дистрибуция на база данни на много Linux платформи и придобива голяма популярност в наши дни. В същото време тя се превръща в много атрактивна система за бази данни за много корпорации. Получава функции, които са близки до нуждите на предприятието, като криптиране, горещо архивиране или съвместимост със собствени бази данни.

Но как новите функции влияят на съвместимостта на MariaDB с MySQL? Все още ли е замяна на MySQL? Как последните промени засилват процеса на миграция? Ще се опитаме да отговорим на това в тази статия.

Какво трябва да знаете, преди да надстроите

MariaDB и MySQL се различават значително една от друга през последните две години, особено с пристигането на най-новите им версии:MySQL 8.0, MariaDB 10.3 и MariaDB 10.4 RC (обсъждахме новите функции на MariaDB 10.4 RC съвсем наскоро, така че ако искате да прочетете повече за това, което предстои в 10.4, моля, проверете два блога на моя колега Кшищоф, Какво е новото в MariaDB 10.4 и втория за Какво е новото в MariaDB Cluster 10.4).

С пускането на MariaDB 10.3, MariaDB изненада мнозина, тъй като вече не е заместител на MySQL. MariaDB вече не обединява новите функции на MySQL с MariaDB noir, които решават грешки в MySQL. Въпреки това версия 10.3 сега се превръща в истинска алтернатива на Oracle MySQL Enterprise, както и на други корпоративни собствени бази данни като Oracle 12c (MSSQL във версия 10.4).

Предварителна проверка и ограничения

Миграцията е сложен процес, независимо до коя версия надграждате. Има няколко неща, които трябва да имате предвид, когато планирате това, като съществени промени между версиите на RDBMS, както и подробно тестване, което трябва да доведе до всеки процес на надграждане. Това е особено важно, ако искате да поддържате наличност по време на надстройката.

Надстройката до нова основна версия е свързана с риск и е важно да планирате внимателно целия процес. В този документ ще разгледаме важните нови промени във версията 10.3 (и предстоящата 10.4) и ще ви покажем как да планирате процеса на тестване.

За да сведем до минимум риска, нека да разгледаме разликите и ограниченията на платформата.

Започвайки с конфигурацията, има някои параметри, които имат различни стойности по подразбиране. MariaDB предоставя матрица на разликите в параметрите. Може да се намери тук.

В MySQL 8.0 caching_sha2_password е плъгинът за удостоверяване по подразбиране. Това подобрение трябва да подобри сигурността чрез използване на алгоритъма SHA-256. MySQL има този плъгин активиран по подразбиране, докато MariaDB не го прави. Въпреки че вече има заявка за функция, отворена с MariaDB MDEV-9804. Вместо това MariaDB предлага плъгин ed25519, който изглежда е добра алтернатива на стария метод за удостоверяване.

Поддръжката на MariaDB за криптиране на таблици и пространства за таблици беше добавена във версия 10.1.3. Тъй като вашите таблици са криптирани, вашите данни е почти невъзможно някой да открадне. Този тип криптиране също така позволява на вашата организация да спазва правителствените разпоредби като GDPR.

MariaDB поддържа пулове на нишки за свързване, които са най-ефективни в ситуации, когато заявките са сравнително кратки и натоварването е свързано с процесора. В изданието на общността на MySQL броят на нишките е статичен, което ограничава гъвкавостта в тези ситуации. Корпоративният план на MySQL включва възможности за пул на нишки.

MySQL 8.0 включва sys схемата, набор от обекти, който помага на администраторите на бази данни и софтуерните инженери да тълкуват данните, събрани от схемата за ефективност. Обектите на Sys схема могат да се използват за случаи на използване на оптимизация и диагностика. MariaDB не включва това подобрение.

Друга е невидимите колони. Невидимите колони дават гъвкавостта при добавяне на колони към съществуващи таблици без страх от счупване на приложение. Тази функция не е налична в MySQL. Позволява създаване на колони, които не са изброени в резултатите от оператор SELECT *, нито е необходимо да им се присвоява стойност в оператор INSERT, когато името им не е споменато в оператора.

MariaDB реши да не внедрява естествена поддръжка на JSON (една от основните характеристики на MySQL 5.7 и 8.0), тъй като твърдят, че не е част от SQL стандарта. Вместо това, за да поддържат репликация от MySQL, те дефинират само псевдоним за JSON, който всъщност е колона LONGTEXT. За да се гарантира, че е вмъкнат валиден JSON документ, функцията JSON_VALID може да се използва като ограничение CHECK (по подразбиране за MariaDB 10.4.3). MariaDB няма директен достъп до MySQL JSON формат.

Oracle автоматизира много задачи с MySQL Shell. В допълнение към SQL, MySQL Shell предлага и възможности за скриптове за JavaScript и Python.

Процес на миграция с помощта на mysqldump

След като знаем нашите ограничения, процесът на инсталиране е доста прост. Това е до голяма степен свързано със стандартната инсталация и импортиране с помощта на mysqldump. Инструментът за архивиране на MySQL Enterprise не е съвместим с MariaDB, така че препоръчителният начин е да използвате mysqldump. Ето примерния процес, който се извършва на Centos 7 и MariaDB 10.3.

Създайте дъмп на MySQL Enterprise сървър

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

Почистете yum кеша индекс

sudo yum makecache fast

Инсталирайте MariaDB 10.3

sudo yum -y install MariaDB-server MariaDB-client

Стартирайте услугата MariaDB.

sudo systemctl start mariadb
sudo systemctl enable mariadb

Защитете MariaDB, като стартирате 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!

Дъмп за импортиране

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

$vi import.log

За разгръщане на среда можете също да използвате ClusterControl, който има опция за внедряване от нулата.

ClusterControl може да се използва и за настройка на репликация или за импортиране на архив от MySQL Enterprise Edition.

Процес на миграция с помощта на репликация

Другият подход за миграция между MySQL Enterprise и MariaDB е да се използва процес на репликация. Версиите на MariaDB позволяват репликация към тях от MySQL бази данни - което означава, че можете лесно да мигрирате MySQL бази данни към MariaDB. Версиите на MySQL Enterprise няма да позволяват репликация от сървърите на MariaDB, така че това е еднопосочен маршрут.

Ето някои общи правила, посочени от MariaDB.

• Репликирането от MySQL 5.5 към MariaDB 5.5+ би трябвало да работи. Ще искате MariaDB да е същата или по-висока версия от вашия MySQL сървър.
• Когато използвате MariaDB 10.2+ като подчинен, може да се наложи да зададете binlog_checksum на NONE.
• Репликирането от MySQL 5.6 без GTID към MariaDB 10+ трябва да работи.
• Репликацията от MySQL 5.6 с GTID, binlog_rows_query_log_events и игнорируеми събития работи, започвайки от MariaDB 10.0.22 и MariaDB 10.1.8. В този случай MariaDB ще премахне MySQL GTID и други ненужни събития и вместо това ще добави свои собствени GTID.

Дори ако не планирате да използвате репликация в процеса на миграция/преминаване, наличието на такава е добро средство за изграждане на доверие е да репликирате вашия производствен сървър в тестова пясъчна среда и след това да практикувате върху него.

Надяваме се, че тази уводна публикация в блога ви е помогнала да разберете процеса на оценка и внедряване на MySQL Enterprise Migration към MariaDB.