MySQLEnterpriseからMariaDB10.3への移行

MySQLと同じ遺産を共有していますが、MariaDBは別のデータベースです。 MySQLとMariaDBの新しいバージョンがリリースされてから何年にもわたって、両方のプロジェクトは2つの異なるRDBMSプラットフォームに異なってきました。

MariaDBは、多くのLinuxプラットフォームでメインのデータベースディストリビューションになり、最近人気が高まっています。同時に、多くの企業にとって非常に魅力的なデータベースシステムになります。暗号化、ホットバックアップ、独自のデータベースとの互換性など、企業のニーズに近い機能を利用できます。

しかし、新機能はMariaDBとMySQLの互換性にどのように影響しますか？それでもMySQLのドロップ代替品ですか？最新の変更は移行プロセスをどのように増幅しますか？この記事でそれに答えようとします。

アップグレード前に知っておくべきこと

MariaDBとMySQLは、特に最新バージョンであるMySQL 8.0、MariaDB 10.3、MariaDB 10.4 RCの登場により、過去2年間で大きく異なります（MariaDB 10.4 RCの新機能についてはごく最近説明したので、必要に応じて10.4の今後の予定について詳しくは、同僚のKrzysztofの2つのブログ、MariaDB10.4の新機能とMariaDBCluster10.4の新機能についてをご覧ください。

MariaDB 10.3のリリースでは、MariaDBはMySQLのドロップイン代替品ではなくなったため、多くの人を驚かせました。 MariaDBは、MySQLのバグを解決するMariaDBnoirと新しいMySQL機能をマージしなくなりました。それにもかかわらず、バージョン10.3は、Oracle MySQL Enterpriseや、Oracle 12c（バージョン10.4のMSSQL）などの他のエンタープライズ独自のデータベースの真の代替手段になりつつあります。

予備チェックと制限

移行は、アップグレードするバージョンに関係なく、複雑なプロセスです。これを計画する際に留意する必要のあることがいくつかあります。たとえば、RDBMSバージョン間の重要な変更や、アップグレードプロセスをリードするために必要な詳細なテストなどです。アップグレード中も可用性を維持したい場合、これは特に重要です。

新しいメジャーバージョンへのアップグレードにはリスクが伴い、プロセス全体を慎重に計画することが重要です。このドキュメントでは、10.3（および今後の10.4）バージョンでの重要な新しい変更点を確認し、テストプロセスを計画する方法を示します。

リスクを最小限に抑えるために、プラットフォームの違いと制限を見てみましょう。

構成から始めて、異なるデフォルト値を持ついくつかのパラメーターがあります。 MariaDBは、パラメーターの違いのマトリックスを提供します。ここにあります。

MySQL 8.0では、caching_sha2_passwordがデフォルトの認証プラグインです。この拡張機能は、SHA-256アルゴリズムを使用してセキュリティを向上させる必要があります。 MySQLではこのプラグインがデフォルトで有効になっていますが、MariaDBでは有効になっていません。 MariaDBMDEV-9804で開かれた機能リクエストはすでにありますが。 MariaDBは、代わりにed25519プラグインを提供しています。これは、古い認証方法の優れた代替手段のようです。

テーブルとテーブルスペースでの暗号化に対するMariaDBのサポートは、バージョン10.1.3で追加されました。テーブルが暗号化されているため、誰かがデータを盗むことはほとんど不可能です。このタイプの暗号化により、組織はGDPRなどの政府規制に準拠することもできます。

MariaDBは、接続スレッドプールをサポートします。これは、クエリが比較的短く、負荷がCPUバウンドである状況で最も効果的です。 MySQLのコミュニティエディションでは、スレッドの数は静的であるため、これらの状況での柔軟性が制限されます。 MySQLのエンタープライズプランにはスレッドプール機能が含まれています。

MySQL 8.0には、データベース管理者とソフトウェアエンジニアがパフォーマンススキーマによって収集されたデータを解釈するのに役立つオブジェクトのセットであるsysスキーマが含まれています。 Sysスキーマオブジェクトは、最適化と診断のユースケースに使用できます。 MariaDBにはこの拡張機能は含まれていません。

もう1つは、非表示の列です。非表示の列は、アプリケーションを壊すことを恐れずに、既存のテーブルに列を追加する柔軟性を提供します。この機能はMySQLでは使用できません。これにより、SELECT *ステートメントの結果にリストされていない列を作成できます。また、ステートメントに名前が記載されていない場合は、INSERTステートメントで値を割り当てる必要もありません。

MariaDBは、ネイティブJSONサポート（MySQL 5.7および8.0の主要機能の1つ）を実装しないことを決定しました。これは、SQL標準の一部ではないと主張しているためです。代わりに、MySQLからのレプリケーションをサポートするために、JSONのエイリアスのみを定義しました。これは実際にはLONG​​TEXT列です。有効なJSONドキュメントが挿入されていることを確認するために、JSON_VALID関数をCHECK制約として使用できます（MariaDB 10.4.3のデフォルト）。 MariaDBはMySQLJSON形式に直接アクセスできません。

Oracleは、MySQLShellを使用して多くのタスクを自動化します。 SQLに加えて、MySQLShellはJavaScriptとPythonのスクリプト機能も提供します。

mysqldumpを使用した移行プロセス

制限がわかれば、インストールプロセスはかなり簡単です。これは、mysqldumpを使用した標準のインストールとインポートにほぼ関連しています。 MySQL EnterpriseバックアップツールはMariaDBと互換性がないため、mysqldumpを使用することをお勧めします。 Centos7とMariaDB10.3で実行されるプロセスの例を次に示します。

MySQLEnterpriseサーバーにダンプを作成する

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

yumキャッシュインデックスをクリーンアップする

sudo yum makecache fast

MariaDB10.3をインストールします

sudo yum -y install MariaDB-server MariaDB-client

MariaDBサービスを開始します。

sudo systemctl start mariadb
sudo systemctl enable mariadb

mysql_secure_installationを実行してMariaDBを保護します。

# 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を使用して、レプリケーションを設定したり、MySQLEnterpriseEditionからバックアップをインポートしたりすることもできます。

レプリケーションを使用した移行プロセス

MySQL EnterpriseとMariaDB間の移行のもう1つのアプローチは、レプリケーションプロセスを使用することです。 MariaDBバージョンでは、MySQLデータベースからそれらに複製できます。つまり、MySQLデータベースをMariaDBに簡単に移行できます。 MySQL Enterpriseバージョンでは、MariaDBサーバーからのレプリケーションが許可されないため、これは一方向のルートです。

MariaDBが指摘する一般的なルールは次のとおりです。

• MySQL5.5からMariaDB5.5+への複製は正常に機能するはずです。 MariaDBをMySQLサーバーと同じかそれ以上のバージョンにする必要があります。
• MariaDB 10.2+をスレーブとして使用する場合、binlog_checksumをNONEに設定する必要がある場合があります。
• GTIDを使用せずにMySQL5.6からMariaDB10+に複製すると機能するはずです。
• GTID、binlog_rows_query_log_events、および無視可能なイベントを使用したMySQL 5.6からのレプリケーションは、MariaDB10.0.22およびMariaDB10.1.8以降で機能します。この場合、MariaDBはMySQL GTIDおよびその他の不要なイベントを削除し、代わりに独自のGTIDを追加します。

移行/カットオーバープロセスでレプリケーションを使用する予定がない場合でも、レプリケーションを使用することは信頼性が高く、本番サーバーをテストサンドボックスにレプリケートしてから練習することをお勧めします。

この紹介ブログ投稿が、MySQLEnterpriseのMariaDBへの移行の評価と実装プロセスを理解するのに役立つことを願っています。