Amazon Web Services ブログ

Amazon Aurora MySQL 3 の MySQL 8.0 互換版が一般提供

Amazon Aurora は、クラウド向けに構築された MySQL および PostgreSQL 互換のリレーショナルデータベースです。Aurora は、従来のエンタープライズデータベースのパフォーマンスと可用性と、オープンソースのデータベースのシンプルさとコスト効率を持ち合わせています。Amazon Aurora MySQL は MySQL 5.7 と互換性に加え、 MySQL 8.0 とも互換性があります。MySQL 8.0 互換の Aurora MySQL 3 が一般提供されています。

Aurora MySQL 3 は、共通テーブル式 (CTE) のサポート、ロールベースの認証、レプリケーションの強化、ウィンドウ関数、インスタント DDL など、いくつかの新機能を導入しています。ローンチ時点で、Aurora MySQL 3 は MySQL 8.0.23 コミュニティエディションとの互換性があり、Aurora がサポートされているすべての AWS リージョン で利用できます。

この投稿では、Aurora MySQL 3 と MySQL Community Edition 8.0 のバージョン間での調整事項、このバージョンがもたらす主な新機能、重大な変更、この新しいバージョンをワークロードに採用するために知っておくべきことなど、この新しいリリースのさまざまな側面について説明します。

MySQL Community Edition マイナーバージョンとのより緊密な互換性

機能と機能性について掘り下げる前に、新しい MySQL Community Edition リリースでのバージョン互換性の維持について、私たちがどのような考え方をしているかについて触れておきましょう。マイナーバージョンの互換性の観点から、すべての Aurora MySQL 2 エンジンバージョンは、MySQL 5.7.12 もしくは 5.7.40 Community Edition とワイヤー互換性があります。 Aurora MySQL との互換性を備えた新機能をリリースしたり、MySQL コミュニティエディションの機能やその他の修正を Aurora マイナーバージョンに提供したりするたびに、個別の Aurora バージョンを維持しています。

Aurora MySQL 3 から、このリリース戦略を MySQL コミュニティエディションのリリースにより密接に追従するように変更します。各 Aurora MySQL 3 リリースは、対応する MySQL 8.0 コミュニティエディションリリースにマッピングされます。たとえば、Aurora MySQL 3.01 は MySQL 8.0.23 にマッピングされ、その特定のコミュニティエディションマイナーバージョンとワイヤー互換性があります。これは、その特定のマイナーバージョンに追加されたすべての修正とコード変更が含まれることを意味します。

Aurora MySQL 3 のマイナーバージョンでは、Aurora 固有の修正と機能の追加だけでなく、MySQL 8.0 コミュニティエディションとの互換性を維持し、コミュニティのバグ修正と機能が継続的に取り入れられるようにします。

Aurora MySQL 2 から Aurora MySQL 3 へのサポートされるアップグレードパス

Aurora MySQL DB クラスタをバージョン 3 にアップグレードする前にアップグレード評価を実行し、対応が必要なすべての項目に対処してください。mysqlcheck--check-upgrade コマンドを使用して評価を実行できます。また、本番の Aurora データベース クラスタのアップグレードを考慮する前に、アップグレードされた Aurora MySQL 3 のバージョンでアプリケーションのテストを行う必要があります。詳細については、この投稿の「動作の変更」の章や、Amazon Aurora ユーザーガイドを確認してください。

起動時に、スナップショットリストアを使用して Aurora MySQL 2 から Aurora MySQL 3 へアップグレードできます。このアップグレードパスを使用するには、現在の Aurora MySQL 2 クラスタのスナップショットを取得し、復元中に Aurora MySQL 3 バージョンを選択する必要があります。Aurora は Aurora MySQL 2 スナップショットを復元し、必要なアップグレード手順を自動的に実行します。新しく復元された DB クラスターは、Aurora MySQL 3 DB インスタンスを使用してデプロイされます。カスタムクラスターまたはインスタンスレベルのパラメータグループを使用している場合は、Aurora MySQL 3 用の新しいカスタムパラメータグループを作成し、Aurora コンソールの 「DB クラスターを復元」ページの「追加設定」 下の 「データベースオプション」 でそれらを選択する必要があります。あるいは、AWS Command Line Interface (AWS CLI) または SDK を使用してリストアする場合は、適切な API 呼び出しに新しいカスタムパラメータグループを指定します。
本番ワークロードの場合、データベースを利用しているワークロードの「常にアクティブ」であるという性質上、アップグレードプロセス中のダウンタイムを最小限に抑えることが望ましい場合があります。ダウンタイムを最小限に抑えたアップグレードを実行するには、まずスナップショットを取得する前に、古い Aurora MySQL 2 DB クラスタでバイナリログレプリケーションを有効にします。その後スナップショットを復元して、Aurora MySQL 3 クラスタとして作成します。これにより、このクラスターにはAurora MySQL 2 クラスタからのすべてのデータが含まれるようになります。Aurora MySQL 2 をソース、 Aurora MySQL 3 をターゲットとしてバイナリログレプリケーションを設定します。Amazon RDS ブルー/グリーンデプロイを利用することで、レプリケーション設定や切り替え手順の簡素化ができます。レプリケーションがすべての変更をキャッチアップした後(レプリケーションが実行されており、レプリカのラグがゼロであることを確認)、レプリケーションを停止し、Aurora MySQL 3 クラスタをプライマリデータベースとして使用を開始できます。

Aurora MySQL 3 で導入された主な新機能

Aurora MySQL 3 は、多くの新しい MySQL 8.0 機能を利用できるようになりました。ユーザーガイドにすべての機能についてのリストがあります。このセクションでは、多くの Aurora のお客様から要望のあった機能を紹介します。

バイナリログの改善

Aurora MySQL はローンチ時からバイナリログレプリケーションをサポートしており、Aurora MySQL 3 でも継続してサポートされています。Aurora MySQL 3 は以前のバージョンと比較して、次のようないくつかの改善点があります:

  • マルチスレッドレプリケーション – Aurora MySQL 3 はマルチスレッド レプリケーション(MTR)をサポートしています。これは、レプリカ DB クラスターで replica_parallel_workers に 0 より大きい値を設定することで有効にできます。MTR は、プライマリ DB インスタンスで高頻度の書き込みを生成するようなワークロードなど、特定のシナリオでバイナリログレプリケーションのパフォーマンスを改善できます。プライマリ DB インスタンスで行われたすべての変更は、レプリカ上で再生する必要があり、同期を取るためです。シングルスレッドのレプリケーションと比較して、マルチスレッド レプリケーションはレプリカ上の変更を並列して適用できるため、レプリケーションラグを短縮できる可能性があります。 
  • レプリケーションフィルタリング – Aurora MySQL 3 はバイナリログのレプリケーション フィルタリングのサポートも取り入れられています。レプリケーションフィルタを使用すると、どのデータベースとテーブルをレプリケートするかを指定できます。レプリケーションフィルタでは、レプリケーションにデータベースやテーブルを含めたり、除外したりできます。replicate-do-*replicate-ignore-* のフィルタリングパラメータを使用して、レプリケーションを実装できます。 
  • バイナリログトランザクション圧縮 – Aurora MySQL 3 でバイナリログトランザクション圧縮を有効にして利用できます。有効にすると、zstd アルゴリズムを使用してトランザクションペイロードが圧縮されます。圧縮されたトランザクションはバイナリログに書き込まれ、圧縮されたまま転送やバイナリログレプリカに保存されます。これにより、プライマリとレプリカの Aurora MySQL クラスタの両方でディスク領域を節約できます。また、ネットワーク帯域幅の消費を抑え、転送時のパフォーマンスが向上します。 

インスタント DDL

Aurora MySQL 3 はインスタント DDL をサポートしています。ALTER TABLE ステートメントの ALGORITHM = INSTANT 句を使用することで、インスタント DDL 機能を利用できます。この機能により、列の追加、列のデフォルト値の設定や削除、テーブルの名前変更など、サポートされているスキーマ変更が大幅に高速化されます。これらのサポートされている DDL 操作は、オンライン (ALGORITHM = INPLACE) やオフライン (ALGORITHM = COPY) の代替 DDL メソッドを使用する場合と比較して大幅に高速に実行されるだけでなく、変更中のテーブルを排他的にロックすることもありません。インスタント DDL 操作では、データディクショナリ内のメタデータのみが変更されます。操作の実行フェーズ中に、テーブルの排他的メタデータロックが一時的に取られることがありますが、テーブルデータは影響を受けないため、操作はほぼ瞬時に完了します。

共通テーブル式

共通テーブル式(CTE) を使用すると、ステートメントのスコープ内で呼び出せる名前の一時的な結果セットを使用できます。CTE を使用することで、複数のサブクエリを作成する場合や再帰クエリを作成する場合に比べて、より簡潔で読みやすい SQL クエリを作成できます。また、サブクエリを複数回記述したり、複数回評価したりすることを避けることで、パフォーマンスの向上にもつながります。CTE は WITH 句 を使用して実装されます。

ウィンドウ関数

ウィンドウ関数を使用することで、分析クエリを改善できます。ウィンドウ関数は集計的な操作ですが、結果を 1 行にまとめるわけではありません。連続するウィンドウに対して集計を行い、行ごとに結果を出力します。Aurora MySQL 3 では、RANK()DENSE_RANK()NTILE()ROW_NUMBER() などのウィンドウ関数をサポートしています。詳細はこちらをご覧ください。

パラレルクエリのサポートの改善

パラレルクエリは、Aurora MySQL 固有の機能で、クエリ処理を Aurora の専用分散ストレージ層に分散して並列化することで、特定の種類のクエリのパフォーマンスを向上させることができます。パラレルクエリの恩恵を受けられるクエリの例として、次のコードに示すように WHERE 句を使用する単純なカウント操作があります。

mysql> explain select count(*) from part where p_partkey > 10 ;
+----+...+----------+------------------------------------------+
| id |...| rows     | Extra                                                                      |
+----+...+----------+------------------------------------------+
|  1 |...| 20427936 | Using where ; Using parallel query (1 columns, 1 filters, 0 exprs ; 0 extra) |
+----+...+----------+------------------------------------------+

Aurora MySQL 3 では、パーティショニングテーブル、集計、HAVING 句、BLOB に対する Aurora パラレルクエリのサポートが追加されました。このサポートにより、集計、パーティション分割テーブル、TEXT、JSON、CHAR、769 バイトを超える VARCHAR などの BLOB データ型を使用するテーブルを利用するクエリで、パラレルクエリのパフォーマンスを最適化できます。

新しいインデックスタイプ

Aurora MySQL 3 では、降順インデックスと非表示インデックスがサポートされるようになりました。降順インデックスは、インデックスを降順にソートして取得する必要があるクエリのパフォーマンスが向上します非表示インデックスを使用すると、実際にインデックスを削除しなくても、インデックスを削除することによるパフォーマンスへの影響をテストできます。この機能を使用して、未使用のインデックスを特定し、スキーマを最適化することができます。

ロール

権限の名前付きコレクションとして機能するロールを作成できるようになりました。ロールを作成および削除したり、ロールに対して権限を付与および取り消すことができます。ユーザーアカウントからロールを付与および取り消すこともできます。Aurora MySQL の以前のバージョンでは、権限を直接付与できるのは個々のユーザーアカウントのみでした。これにより、ユーザーグループへの権限の付与と取り消しが効率化され、ユーザー管理全体が簡素化されます。詳細については、Using Rolesを参照してください。

Amazon RDS for MySQL 5.7/8.0 から Aurora MySQL 3 へのサポートされる移行パス

Amazon Relational Database Service (Amazon RDS) for MySQL から Aurora MySQL 3 への移行を検討している場合、次の移行パスが利用できます:

  • スナップショットの復元 – MySQL 8.0 (MySQL バージョン 8.0.23 以下) のスナップショットから Aurora MySQL 3 への復元ができます。プロセスは Aurora のアップグレードセクションで説明したものと同じです。 
  • リードレプリカの移行 – Amazon RDS for MySQL 8.0 プライマリ DB インスタンス (MySQL バージョン 8.0.23 以下) から、Aurora MySQL 3 リードレプリカ DB クラスタを作成できます。このプロセスでは自動的に、MySQL DB インスタンスからすべてのデータを含む Aurora MySQL 3 DB クラスタが作成され、Amazon RDS for MySQL ソースから Aurora MySQL ターゲットへのバイナリログレプリケーションが設定されます。リードレプリカ DB クラスタが作成され、すべての変更をキャッチアップした後 (レプリケーションが実行されており、レプリカのラグがゼロであることを確認)、スタンドアロンのプライマリ DB クラスタに昇格させて、読み取りと書き込みを受け入れることができます。 

これらの方法は、Amazon RDS for MySQL 8.0 からの移行にのみ適用できます。Amazon RDS for MySQL 5.7 から Aurora MySQL 3 への移行にはこの方法を使用できません。
Amazon RDS for MySQL 5.7 から Aurora MySQL 3 への移行は、2 段階のプロセスになります。まず、Amazon RDS for MySQL 5.7 DB インスタンスを Amazon RDS for MySQL 8.0 にアップグレードする必要があります。その後、上記で説明した 2 つの移行方法のいずれかを使用します。

他のセルフマネージド MySQL 互換データベースからのサポートされている移行パス

現時点では論理データのエクスポートを実行して新しい Aurora MySQL 3 DB クラスターにインポートすることで、、セルフマネージド MySQL 互換データベースからの移行ができます。 バイナリログレプリケーションを使用すると、他のアップグレードソースまたは移行ソースの前のセクションで説明したように、ダウンタイムを最小限に抑える移行を実行できます。 バイナリログレプリケーションの設定は、Amazon Aurora ユーザーガイドで詳しく説明されています。 この移行は、コミュニティやサードパーティが提供するネイティブな MySQL ツール(mysqldump、mydumper/myloader など)を使用するか、AWS データベース移行サービス(AWS DMS) を使用することで実行できます。

Aurora MySQL 3 への Aurora MySQL 1 および 2 からの動作変更

Aurora MySQL 3 では、新しい機能に加えて、クエリに対するデータベースの動作や、内部構造の運用や管理方法が変わる可能性のある変更もいくつか導入されています。データベースのアップグレードを検討する前に、アップグレード前の評価を実施して、アップグレード前に対応が必要な項目に確実に対処することを強くお勧めします。動作には次のような重要な変更点があります。変更の完全なリストについては、MySQL 8.0 の変更点を参照してください。

TempTable ストレージエンジン

MySQL 8.0 では、複雑なクエリを処理する際にデータベースエンジンが内部的に一時テーブルを作成するのに使用される新しい TempTable ストレージエンジンがデフォルトとして導入されました。Aurora MySQL 3 でも、TempTable ストレージエンジンをデフォルトとして導入しています。TempTable は、内部テンポラリテーブルを格納するために一定量のメモリを割り当てるだけでなく、メモリに収まらない大きなデータセットを、メモリマップファイル、InnoDB ストレージエンジンのいずれかに流出させたり、カスケードしてメモリマップファイルや InnoDB ストレージエンジンに流出させたり、両方にカスケードしたりすることがあります。Aurora MySQL の場合は共有ストレージアーキテクチャを使用するため、InnoDB テーブルはクラスタのリーダー DB インスタンスで読み取り専用モードでのみアクセスできます。その結果、リーダー DB インスタンスは内部一時テーブルにメモリマップドファイルのみを使用でき、DB インスタンスクラスに対応する割り当てられた一時ストレージスペースの量に限定されます。Aurora MySQL 3 DB クラスターのライター DB インスタンスは、メモリマップファイルと InnoDB ストレージのいずれかまたは両方を使用するように設定できます。

TempTable エンジンは、VARCHAR、VARBINARY、およびその他の BLOB データ型をより効率的に格納できます。固定長の行形式を使用していた MEMORY ストレージエンジンと比較して、TempTable ストレージエンジンは VARCHAR、VARBINARY、その他の BLOB 列を、可変長のセル配列を使用して格納します

データディクショナリの変更

Aurora MySQL 3 は、データディクショナリ(メタデータ)の保持方法が変更されました。以前のバージョンでは、データディクショナリは非リレーショナルなメタデータファイル(FRM、TRN、TRG、OPT ファイルなど)を使用して保持されていましたが、現在はデータディクショナリはトランザクションスキーマに格納されるようになりました。この新しい実装には、クラッシュセーフなデータディレクトリスキーマ、一元化されたメタデータによる簡潔さ、ディクショナリオブジェクトの統一キャッシング、アトミック DDLなど、いくつかのメリットがあります。新しい実装のメリットの完全なリストについては、MySQL データディクショナリを参照してください。

エラーコードの削除

いくつかのエラーコードが削除されました。アプリケーションでエラー処理に MySQL の特定のエラーコードを使用している場合は、アプリケーションに適切な変更を加える必要があります。詳細は、MySQL 8.0 で削除された機能をご覧ください。

GROUP BY の ASC/DESC 句

GROUP BY 句で ASC または DESC 修飾子を使用しているクエリの場合、これらは Aurora MySQL のこのバージョンで削除されているため、機能しなくなります。 GROUP BY で ASC または DESC 修飾子を使用したクエリの結果を並べ替える必要がある場合は、代わりに ORDER BY 句で ASC または DESC 修飾子を使用するようにクエリを変更する必要があります。

Aurora MySQL のメジャーバージョンの選択方法

Aurora MySQL のメジャーバージョンの選択は、主に特定のアプリケーションの互換性要件、新しいメジャーバージョンのテストのためのリソース、必要な機能へのアクセス可否に大きく依存します。ワークロードを将来にわたって利用できるようにし、最新機能にアクセスすることを優先する場合は、Aurora MySQL 3 (MySQL 8.0 互換) を検討する必要があります。同様に、バージョン 3 で実行することで、Aurora DB インスタンスクラスの形式で最新のハードウェアにアクセスできるようになります。また、新しいワークロードを作成していて、レガシーコードがない場合は、最新バージョンの Aurora MySQL の使用を検討する必要があります。

Aurora MySQL チームは、まずバージョン 3 プラットフォームでの新機能の開発とリリースに注力します。Aurora MySQL 3 の長期サポート (LTS) バージョンもリリースされています。このバージョンでは、ソフトウェアの更新がセキュリティとバグ修正に限定され、新機能によるワークロードの動作の変化のリスクがないことが保証されます。
これは、バージョンポリシー(各メジャーバージョンの Aurora MySQL に 1 つの LTS バージョン)に沿ったものです。

まとめ

この投稿では、MySQL 8.0 エンジン互換性を備えた新しい Aurora MySQL 3 の一般提供可能性について説明しました。新しくエキサイティングな機能のサポート、動作の変更、アップグレードと移行オプション、マイナーバージョン互換性の観点での考え方の変化について説明しました。

新プラットフォームのすべての機能とメリットを活用していただけることを楽しみにしています。
すぐにMySQL 8.0 との互換性がある新しい Aurora MySQL 3 データベースクラスターを起動をお試しください。

著者について

Aditya SamantAditya Samant  は、AWS のデータベースを専門とするソリューションアーキテクトです。AWS のお客様が最先端のクラウドテクノロジーを活用した、スケーラブルで安全で堅牢なアーキテクチャを 設計できるよう支援しています。プライベートではレトロな PC テクノロジーを楽しんだり、コンピューターゲームをしたり、家族や友人と時間を過ごしたりしています。

Vlad Vlasceanu は、AWS のスペシャリストソリューションアーキテクトです。彼はお客様と協力してデータベースプロジェクトに関するガイダンスや技術支援を行い、お客様が AWS を使用する際のソリューションの価値向上を支援しています。