MariaDB 10.4は、MariaDBの現在の開発ブランチです。最近、5月21日に3番目のリリース候補（10.4.5）がリリースされ、公式リリースに近づきました。そのため、10.4の新機能を確認することをお勧めします。また、MariaDBCorporationによって公開された最近のブログ投稿についていくつかの考えを共有します。リリース自体の詳細については、MariaDB10.4.0の変更ログですべての詳細を確認できます。
パフォーマンスの変更
Unicode文字セットは通常、latin1のような文字セットよりも低速ですが、これは主にサイズが原因です。 MySQL 8.0はこの分野で大幅な改善をもたらし、MariaDB10.4もこの点で10.3よりも著しく高速になるはずです。これは非常に重要な改善です。人々は、UTF8を有効にする必要がある絵文字を使用するのが大好きです。オプティマイザーでいくつかの作業が行われました。MariaDB10.4は、条件をマテリアライズドサブクエリにプッシュできるようになったため、IN（）サブクエリでより適切に機能するはずです。
REDOログのデータ量によっては、InnoDBの起動と停止に時間がかかる場合があります。 MariaDB 10.4は、起動、シャットダウン、およびパージを改善します。 mariabackupやxtrabackupなどのホットバックアップツールの人気を考えると、このような改善は特に重要です。これらのツールは、最終的に、REDOログを適用するときに、クリーンでないシャットダウンからInnoDB起動プロセスを実行します。したがって、その領域ですべての改善を行うと、バックアップの復元に必要な時間が短縮されます。
InnoDBの変更
MariaDB 10.4は、インスタントDROPCOLUMN操作を受け取りました。テーブルを再構築せずに、テーブル内の列を並べ替えることもできるようになりました。これがどれほど重要かを強調することはできません。実稼働環境で行う最も一般的な操作は何ですか？インデックスを追加または削除していると言えます。もう1つの最も一般的な操作は、列に対する操作です。新しい列を追加し、既存の列を削除します。これまでのところ、最も一般的なアプローチは、外部ツールを使用して作業を行うことでした。pt-online-schema-change、または最近ではgh-ostです。どちらにも制限があり（たとえば、gh-ostはGalera Clusterでは機能しません）、システムで使用できなくなる可能性があります。特にトリッキーなのは外部キーです。インスタントDROPCOLUMN（インスタントADD COLUMNはすでに使用可能です）を使用すると、スキーマの変更の大部分を、詳細なスケジューリングや計画を行わなくても、アドホックで実行できます。瞬時の変更が私たちが望んでいることであることを覚えておくことが重要です。インデックスの作成など、非ブロッキングスキーマの変更がありますが、レプリケーションラグを引き起こすため、レプリケーションを使用する場合、このような操作は深刻な問題を引き起こします。したがって、操作がライブシステムで実行された可能性がある場合でも、プロセスをより適切に制御するために、pt-online-schema-changeなどの回避策を使用することをお勧めします。
スキーマ変更の実行方法の改善はこれだけではありません。 MariaDB 10.4は、VARCHAR列のより高速な拡張の恩恵を受け、さらに、インデックス付けされていない列での文字セットと照合の変更が即座に行われます。
一般的な変更
最大の変更点の1つは、ユーザー管理の変更です。 Mysql.hostテーブルは作成されません。mysql.userテーブルは非推奨になります。ユーザーアカウントとグローバル権限はmysql.global_privテーブルに保持されます。これは、MySQLおよびMariaDBユーザーを管理するオプションを持つすべてのツール（ClusterControlを含む）にとって重大な変更になる可能性があります。MariaDB10.4以降のユーザー管理をカバーするために、新しいケースを作成する必要があります。変更が必要であることは承知していますが、これはMariaDBとMySQLの両方のツールを維持するのに確実に役立つわけではなく、ツールの状況が以前よりもさらに分割されています。ユーザーについて言えば、MariaDB 10.4には、ユーザーパスワードを期限切れにするオプションが付属しています。これは間違いなく良い方向への一歩です。パスワード管理に関する優れた慣行を実施するのに役立ちます。
別のブログで詳しく説明しますが、ここでGalera26.4のサポートについて言及する必要があります。MariaDB10.4は、ストリーミングレプリケーションやバックアップロックのおかげで改善されたSSTなどの機能を備えた新しいGaleraバージョンの恩恵を受けます。
最後に、MariaDB 10.4では、sql_mode=MSSQLを設定できます。これは初期実装ですが、sql_mode=ORACLEもある時点で初期実装でした。これは、MariaDBがエンタープライズ顧客に焦点を合わせていることを示しています。Oracleの顧客が移行を決定した場合、機能が追加され、移行の問題が少なくなるため、MicrosoftSQLServerでのMariaDBの採用も増える可能性があります。
MariaDBがフォークであること
ごく最近、InnoDBの変更と互換性に関するMariaDBのスタンスを説明するブログ投稿を目にしました。要点は、MariaDBがMySQLのInnoDB機能をマージしなくなり、MariaDBによって行われる安定性とパフォーマンスの向上に焦点が当てられることです。これは基本的に、MariaDBがMySQLと互換性がなくなることを意味します。過去にバイナリアップグレードを実行できたとしても、将来は実行できなくなります。現在でも、実行するのは難しい場合があります。これにより、論理バックアップが移行の唯一の方法になるため、mydumper/myloaderなどのツールの重要性が高まります。良いことに、MariaDBはInnoDBのフォークの安定性を所有できるようになります。上流の開発者によって導入された問題に対処する必要がないため、導入されるバグが少なくなると期待できます。
パフォーマンスに関しては、ベンチマークを待つ必要がありますが、履歴データを考えると、MariaDBはMySQLよりも遅いと想定できます。過去のベンチマークで私たちが通常目にするのは、MariaDBのパフォーマンスの向上は、より新しいバージョンのInnoDBが統合されたときに始まるということです。これは、MariaDBが今後のパフォーマンス比較でどのように機能するのか、そしてMariaDBによって導入された改善がMySQL8.0以降のバージョンに追いつくのに十分であるのかどうか疑問に思うようなケースではなくなります。
私たちのユーザーにとって、これはすべて、MariaDB10.4が以前のリリースよりも安定している必要があることを意味します。また、最終的には2つの異なるストレージエンジンの内部を学習する必要があることも意味します。特にパフォーマンスを重視する場合はそうです。これは理想からはほど遠いですが、そうです。ツールは、いずれかのバージョンのInnoDBで動作するように設計する必要があります（または、MySQLとMariaDBの両方をサポートするために追加の作業を追加する必要があります）。これがどのように進行するかを見守っていきます。あなたがそれについて考えるとき、それはそれほど驚くべき動きではありません-MariaDBは常により新しいバージョンのInnoDBと統合するために時間をかけなければなりませんでした。互換性のない機能がMariaDBに追加され、MySQL 8.0で大幅な変更が加えられているため、互換性のないInnoDBをアップストリームのMySQLから移植するのではなく、新しい機能の開発に集中するのが理にかなっています。
この短いブログ投稿が、MariaDB10.4に移行するときに本番システムに影響を与える変更についての洞察を提供してくれることを願っています。