Aurora MySQL バージョン 3 は MYSQL 8.0 との互換性があります。 - Amazon Aurora

Aurora MySQL バージョン 3 は MYSQL 8.0 との互換性があります。

Aurora MySQL バージョン 3 を使用して、MySQL 互換の最新機能、パフォーマンスの強化、およびバグ修正を入手できます。以下では、MySQL 8.0 の互換性を持つ Aurora MySQL バージョン 3 について学ぶことができます。クラスターとアプリケーションを Aurora MySQL バージョン 3 にアップグレードする方法を学ぶことができます。

Aurora Serverless v2 など、Aurora の一部の機能は、Aurora MySQL バージョン 3 を必要とします。

コミュニティMySQL 8.0 からの機能

Aurora MySQL バージョン 3 の初期リリースは コミュニティ MySQL 8.0.23 と互換性があります。MySQL 8.0 では、以下を含むいくつかの新機能が導入されています。

  • JSON 関数。使用に関する情報については、MySQL リファレンスマニュアルJSON 関数を参照してください。

  • ウィンドウ関数。使用に関する情報については、MySQL リファレンスマニュアルWindow 関数を参照してください。

  • WITH 句を使用した共通テーブル表現 (CTE)。使用に関する情報については、MySQL リファレンスマニュアルWITH (共通テーブル表現)を参照してください。

  • ALTER TABLE ステートメントの、最適化された ADD COLUMNRENAME COLUMN 句 。これらの最適化は「インスタント DDL」と呼ばれます。Aurora MySQL バージョン 3 はコミュニティ MySQL インスタント DDL 特徴と互換性があります。旧 Aurora 高速 DDL特徴は使用されていません。インスタント DDL の使用情報については、インスタント DDL (Aurora MySQL バージョン 3) を参照してください。

  • 降順、機能、不可視インデックス。使用に関する情報については、MySQL リファレンスマニュアル非表示インデックス降順インデックス、およびCREATE INDEX インデックスを参照してください。

  • SQL 文で制御されるロールベースの権限。権限モデルの変更については、ロールベースの特権モデル を参照してください。

  • SELECT ... FOR SHARE 文のNOWAITSKIP LOCKED 句。これらの句は、他のトランザクションが行ロックを解放するのを待つことを避けます。使用の詳細については、MySQL リファレンスマニュアル読み取りロックを参照してください。

  • バイナリログ (binlog) のレプリケーションの改善。Aurora MySQL の詳細については、バイナリログレプリケーション を参照してください。特に、フィルタリングされたレプリケーションを実行できます。使用方法については、MySQL リファレンスマニュアルサーバがレプリケーションフィルタ規則を評価する方法を参照してください。

  • ヒント。MySQL 8.0 互換ヒントのいくつかは、既に Aurora MySQL バージョン 2 にバックポートされています。Aurora MySQL でのヒントの使用については、Aurora MySQL のヒント を参照してください。コミュニティ MySQL 8.0 でのヒントの詳細なリストは、MySQL リファレンスマニュアルオプティマイザーヒントを参照してください。

MySQL 8.0 コミュニティエディションに追加された機能の完全なリストについては、ブログ記事 MySQL 8.0 の新機能の完全なリスト を参照してください。

Aurora MySQL バージョン 3 には、コミュニティ MySQL 8.0.26 からバックポートされた、包括的言語キーワードの変更も含まれています。これらの変更の詳細については、Aurora MySQL バージョン 3 に対する包括的な言語変更 を参照してください。

新しいパラレルクエリの最適化

Aurora パラレルクエリの最適化は、より多くの SQL 操作に適用されるようになりました。

  • パラレルクエリは、TEXTBLOBJSONGEOMETRYVARCHAR、そして 768 バイトより長い CHAR のデータ型を含んだテーブルに適用されるようになりました。

  • パラレルクエリは、パーティショニングテーブルを含むクエリを最適化できます。

  • パラレルクエリは、選択リストと HAVING 句内でする集計関数の呼び出を伴うクエリを最適化できます。

強化の詳細については、Aurora MySQL バージョン 3 への パラレルクエリクラスターのアップグレード を参照してください。Aurora パラレルクエリの一般情報については、Amazon Aurora MySQL のパラレルクエリの使用 を参照してください。

Aurora MySQL サーバーレス v2 の前提条件である Aurora MySQL バージョン 3

Aurora MySQL バージョン 3 は、Aurora MySQL サーバーレス v2 クラスター内のすべての DB インスタンスの前提条件です。Aurora MySQL サーバーレス v2 には、DB クラスター内のリーダーインスタンスのサポートと、Aurora MySQL サーバーレス v1 では利用できない Aurora 機能のサポートが含まれています。また、Aurora MySQL サーバーレス v1 よりも高速かつきめ細かなスケーリングも備えています。

Aurora MySQL バージョン 3 のリリースノート

すべての Aurora MySQL バージョン 3 リリースのリリースノートについては、Aurora MySQL のリリースノートの「Amazon Aurora MySQL バージョン 3 のデータベースエンジンの更新」を参照してください。

Aurora MySQL バージョン 2 と Aurora MySQL バージョン 3 の比較

Aurora MySQL バージョン 2 クラスターをバージョン 3 にアップグレードする際に注意すべき変更については、以下を参照してください。

Aurora MySQL バージョン 2 と 3 の特徴の違い

次の Amazon Aurora MySQL 機能は Aurora MySQL 5.7 でサポートされていますが、これらの機能は現在 MySQL 8.0 の Aurora MySQL ではサポートされていません。

  • バックトラックは現在、Aurora MySQL バージョン 3 クラスターでは使用できません。この機能は後続のマイナーバージョンで使用できるようにする予定です。

    バックトラックを使用する Aurora MySQL バージョン 2 クラスターがある場合、スナップショットの復元方法を使用して Aurora MySQL バージョン 3 にアップグレードすることは現状できません。この制限は、バックトラック設定がオンになっているかどうかにかかわらず、バックトラッククラスターを使用するすべてのクラスターに適用されます。アップグレード手順の詳細については、Aurora MySQL バージョン 3 へのアップグレード を参照してください。

  • Aurora Serverless v1 クラスターに Aurora MySQL バージョン 3 を使用することはできません。Aurora MySQL バージョン 3 は Aurora Serverless v2 で動作します。

  • ラボモードは Aurora MySQL バージョン 3 には適用されません。Aurora MySQL バージョン 3 には、ラボモードの機能はありません。インスタント DDL は、過去にラボモードで使用可能だった高速オンライン DDL特徴よりも優先されます。例については、「インスタント DDL (Aurora MySQL バージョン 3)」をご参照ください。

  • クエリキャッシュはコミュニティ MySQL 8.0 から削除され、Aurora MySQL バージョン 3 からも削除されます。

  • Aurora MySQL バージョン 3 はコミュニティ MySQL ハッシュ統合特徴と互換性があります。ハッシュ結合の Aurora 固有の実装は Aurora MySQL バージョン 2 では使用されていません。ハッシュ結合を Aurora パラレルクエリで使用する方法については、パラレルクエリクラスターのハッシュ結合の有効化 および Aurora MySQL のヒント を参照してください。ハッシュ結合の一般的な使用方法については、MySQL リファレンスマニュアルハッシュ結合の最適化を参照してください。

  • 現在、Percona XtraBackup ツールから Aurora MySQL バージョン 3 クラスターに物理バックアップを復元することはできません。この特徴は、後続のマイナーバージョンでサポートする予定です。

  • Aurora MySQL バージョン 2 で非推奨であったた mysql.lambda_async ストアドプロシージャは、バージョン 3 で削除されます。バージョン 3 では、非同期関数 lambda_async を代わりに使用します。

  • Aurora MySQL バージョン 3 のデフォルト文字セットは utf8mb4 です。Aurora MySQL バージョン 2 のデフォルト文字セットは latin1 です。この文字セットの詳細については、MySQL リファレンスマニュアルutf8mb4 文字セット (4 バイトの UTF-8 Unicode エンコード)を参照してください。

  • innodb_flush_log_at_trx_commit 構成パラメータは変更できません。デフォルト値の 1 は常に適用されます。

Aurora MySQL の一部の機能は、AWS リージョンと DB エンジンのバージョンの特定の組み合わせで利用可能です。詳細については、「」を参照してくださいAWS リージョン と Aurora DB エンジンにより Amazon Aurora でサポートされている機能

インスタンスクラスのサポート

Aurora MySQL バージョン 3 では、Aurora MySQL バージョン 2 とは異なるインスタンスクラスのセットがサポートされています。

  • 大規模なインスタンスの場合は、db.r5db.r6gdb.x2g のような最新のインスタンスクラスを使用できます。

  • 小規模なインスタンスの場合は、db.t3db.t4g のような最新のインスタンスクラスを使用できます。

Aurora MySQL バージョン 2 の以下のインスタンスクラスは、Aurora MySQL バージョン 3 では使用できません。

  • db.r4

  • db.r3

  • db.t3.small

  • db.t2

Aurora MySQL DB インスタンスを作成する CLI ステートメントと、Aurora MySQL バージョン 3 では利用できないインスタンスクラス名を、ハードコードしていないかどうかを管理スクリプトでチェックします。必要に応じて、Aurora MySQL バージョン 3 がサポートするインスタンス名に、インスタンスクラス名を変更します。

ヒント

Aurora MySQL バージョンと AWS リージョンの特定の組み合わせに使えるインスタンスクラスをチェックするには、describe-orderable-db-instance-options AWS CLI コマンドを使用して下さい。

Aurora インスタンスクラスの詳細については、Aurora DB インスタンスクラス を参照してください。

Aurora MySQL バージョン 3 のパラメータ変更

Aurora MySQL バージョン 3 には、新しいクラスターレベルおよびインスタンスレベルの設定パラメータが含まれています。Aurora MySQL バージョン 3 では、Aurora MySQL バージョン 2 に存在していたいくつかのパラメータも削除されます。一部のパラメータ名は、包括語のイニシアチブの結果として変更されます。下位互換性のために、古い名前または新しい名前を使用してパラメータ値を取得できます。ただし、カスタム パラメータグループ内のパラメータ値を指定するには、新しい名前を使用する必要があります。

Aurora MySQL バージョン 3 では、lower_case_table_names パラメータ値はクラスターの作成時に永続的に設定されます。このオプションにデフォルト以外の値を使用する場合は、アップグレードする前に Aurora MySQL バージョン 3 のカスタム パラメータグループを設定します。次に、クラスターの作成またはスナップショットの復元操作中にパラメータグループを指定します。

すべての Aurora MySQL クラスター パラメータのリストについては、クラスターレベルのパラメータ を参照してください。この表では、Aurora MySQL バージョン 1、2、および 3 のすべてのパラメータについて説明します。この表には、Aurora MySQL バージョン 3 で新しく追加されたパラメータや Aurora MySQL バージョン 3 から削除されたパラメータを示す注記が含まれています。

すべての Aurora MySQL インスタンス パラメータのリストについては、インスタンスレベルのパラメータ を参照してください。この表では、Aurora MySQL バージョン 1、2、および 3 のすべてのパラメータについて説明します。この表には、Aurora MySQL バージョン 3 で新しく追加されたパラメータがどれか、また Aurora MySQL バージョン 3 から削除されたパラメータはどれかを示した注記が含まれています。また、Aurora MySQL バージョン 3 ではなく、以前のバージョンで変更可能なパラメータを示す注記も含まれています。

変更されたパラメータ名の詳細については、Aurora MySQL バージョン 3 に対する包括的な言語変更 を参照してください。

ステータス可変

Aurora MySQL に適用できないステータス可変の詳細については、Aurora MySQL に適応されない MySQL ステータス可変 を参照してください。

Aurora MySQL バージョン 3 に対する包括的な言語変更

Aurora MySQL バージョン 3 は MySQL コミュニティ エディションのバージョン 8.0.23 と互換性があります。Aurora MySQL バージョン 3 には、包括語のキーワードやシステムスキーマに関連した MySQL 8.0.26 からの変更も含まれています。例えば、今では SHOW SLAVE STATUS の代わりにSHOW REPLICA STATUS コマンドが優先されるようになりました。

次の Amazon CloudWatch メトリクスには、Aurora MySQL バージョン 3 の新しい名前が付けられています。

Aurora MySQL バージョン 3 では、新しいメトリクス名のみを使用できます。Aurora MySQL バージョン 3 にアップグレードするときは、メトリクス名に依存するアラームやその他のオートメーションを必ず更新してください。

現在の名前 新しい名前
ForwardingMasterDMLLatency ForwardingWriterDMLLatency
ForwardingMasterOpenSessions ForwardingWriterOpenSessions
AuroraDMLRejectedMasterFull AuroraDMLRejectedWriterFull
ForwardingMasterDMLThroughput ForwardingWriterDMLThroughput

Aurora MySQL バージョン 3 では、次のステータス可変に新しい名前が追加されました。

Aurora MySQL バージョン 3 の初期のリリースでは、互換性のためにいずれかの名前を使用できます。古いステータス可変名は、将来のリリースで削除される予定です。

削除される名前 新しい名前または優先される名
Aurora_fwd_master_dml_stmt_duration Aurora_fwd_writer_dml_stmt_duration
Aurora_fwd_master_dml_stmt_count Aurora_fwd_writer_dml_stmt_count
Aurora_fwd_master_select_stmt_duration Aurora_fwd_writer_select_stmt_duration
Aurora_fwd_master_select_stmt_count Aurora_fwd_writer_select_stmt_count
Aurora_fwd_master_errors_session_timeout Aurora_fwd_writer_errors_session_timeout
Aurora_fwd_master_open_sessions Aurora_fwd_writer_open_sessions
Aurora_fwd_master_errors_session_limit Aurora_fwd_writer_errors_session_limit
Aurora_fwd_master_errors_rpc_timeout Aurora_fwd_writer_errors_rpc_timeout

Aurora MySQL バージョン 3 では、次の設定パラメータに新しい名前が付けられました。

互換性のため、mysql クライアントのパラメータ値をチェックするには、Aurora MySQL バージョン 3 の初期のリリースでいずれかの名前を使用します。カスタムパラメータグループ内の値は、新しい名前を使用してのみ変更できます。古いパラメータ名は、将来のリリースで削除される予定です。

削除される名前 新しい名前または優先される名
aurora_fwd_master_idle_timeout aurora_fwd_writer_idle_timeout
aurora_fwd_master_max_connections_pct aurora_fwd_writer_max_connections_pct
master_verify_checksum source_verify_checksum
sync_master_info sync_source_info
init_slave init_replica
rpl_stop_slave_timeout rpl_stop_replica_timeout
log_slow_slave_statements log_slow_replica_statements
slave_max_allowed_packet replica_max_allowed_packet
slave_compressed_protocol replica_compressed_protocol
slave_exec_mode replica_exec_mode
slave_type_conversions replica_type_conversions
slave_sql_verify_checksum replica_sql_verify_checksum
slave_parallel_type replica_parallel_type
slave_preserve_commit_order replica_preserve_commit_order
log_slave_updates log_replica_updates
slave_allow_batching replica_allow_batching
slave_load_tmpdir replica_load_tmpdir
slave_net_timeout replica_net_timeout
sql_slave_skip_counter sql_replica_skip_counter
slave_skip_errors replica_skip_errors
slave_checkpoint_period replica_checkpoint_period
slave_checkpoint_group replica_checkpoint_group
slave_transaction_retries replica_transaction_retries
slave_parallel_workers replica_parallel_workers
slave_pending_jobs_size_max replica_pending_jobs_size_max
pseudo_slave_mode pseudo_replica_mode

Aurora MySQL バージョン 3 では、次のストアドプロシージャは新しい名前になっています。

Aurora MySQL バージョン 3 の初期のリリースでは、互換性のためにいずれかの名前を使用できます。以前のプロシージャ名は、将来のリリースで削除される予定です。

削除される名前 新しい名前または優先される名
mysql.rds_set_master_auto_position mysql.rds_set_source_auto_position
mysql.rds_set_external_master mysql.rds_set_external_source
mysql.rds_set_external_master_with_auto_position mysql.rds_set_external_source_with_auto_position
mysql.rds_reset_external_master mysql.rds_reset_external_source
mysql.rds_next_master_log mysql.rds_next_source_log

AUTO_INCREMENT 値

Aurora MySQL バージョン 3 では、各 DB インスタンスを再起動する際、Aurora は 各テーブルの AUTO_INCREMENT 値を保持します。Aurora MySQL バージョン 2 では、再起動後に AUTO_INCREMENT 値が保持されませんでした。

スナップショットからの復元や、ポイントインタイムリカバリの実行、およびクラスターのクローン作成によって新しいクラスターを設定した場合、AUTO_INCREMENT 値は保持されません。この場合の AUTO_INCREMENT 値は、スナップショットが作成された時点のテーブル内の最大列値に基づいた値に初期化されます。この動作は、RDS for MySQL 8.0 では異なり、AUTO_INCREMENT 値はこれらのオペレーション中に保持されます。

リーダー DB インスタンスのテンポラリテーブル

Aurora MySQL リーダーインスタンスで InnoDB ストレージエンジンを使用してテンポラリテーブルを作成することはできません。リーダーインスタンスでは、InnoDB ストレージエンジンは読み取り専用として構成されます。リーダーインスタンス上のすべての CREATE TEMPORARY TABLE ステートメントは、 NO_ENGINE_SUBSTITUTION SQL モードが無効な状態で実行されているか必ず確認してください。

受け取るエラーは、プレーン CREATE TEMPORARY TABLE ステートメントまたはバリエーション CREATE TEMPORARY TABLE AS SELECT を使うかどうかによって異なります。次の例では、さまざまなタイプのエラーを示しています。

このテンポラリテーブルの動作は、読み取り専用インスタンスにのみ適用されます。この初期の例では、セッションが接続されているインスタンスの種類を確認します。

mysql> select @@innodb_read_only; +--------------------+ | @@innodb_read_only | +--------------------+ | 1 | +--------------------+

プレーン CREATE TEMPORARY TABLE ステートメントの場合、NO_ENGINE_SUBSTITUTION SQL モードが有効になっているとステートメントは失敗します。SQL モードが無効の場合、成功します。

mysql> set sql_mode = 'NO_ENGINE_SUBSTITUTION'; mysql> CREATE TEMPORARY TABLE tt2 (id int) ENGINE=InnoDB; ERROR 3161 (HY000): Storage engine InnoDB is disabled (Table creation is disallowed). mysql> SET sql_mode = ''; mysql> CREATE TEMPORARY TABLE tt4 (id int) ENGINE=InnoDB; mysql> SHOW CREATE TABLE tt4\G *************************** 1. row *************************** Table: tt4 Create Table: CREATE TEMPORARY TABLE `tt4` ( `id` int DEFAULT NULL ) ENGINE=MyISAM DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci

CREATE TEMPORARY TABLE AS SELECT ステートメントの場合、NO_ENGINE_SUBSTITUTION SQL モードの有効/無効に関わらず、ステートメントは失敗します。MySQL コミュニティエディションは、CREATE TABLE AS SELECT または CREATE TEMPORARY TABLE AS SELECT ステートメントとのストレージエンジンの置換をサポートしていません。これらのステートメントについては、SQL コードから ENGINE=InnoDB 句を削除します。

mysql> set sql_mode = 'NO_ENGINE_SUBSTITUTION'; mysql> CREATE TEMPORARY TABLE tt1 ENGINE=InnoDB AS SELECT * FROM t1; ERROR 3161 (HY000): Storage engine InnoDB is disabled (Table creation is disallowed). mysql> SET sql_mode = ''; mysql> CREATE TEMPORARY TABLE tt3 ENGINE=InnoDB AS SELECT * FROM t1; ERROR 1874 (HY000): InnoDB is in read only mode.

Aurora MySQL バージョン 3 でのテンポラリテーブルのストレージ側面とパフォーマンスへの影響の詳細については、ブログ記事「Use the TempTable storage engine on Amazon RDS for MySQL and Amazon Aurora MySQL」(Amazon RDS for MySQL および Amazon Aurora MySQL の TempTable ストレージエンジンを使用する) を参照してください。

内部テンポラリテーブルのストレージエンジン

Aurora MySQL バージョン 3 では、内部テンポラリテーブルの動作方法は、以前の Aurora MySQL バージョンとは異なります。このようなテンポラリテーブルの InnoDB ストレージエンジンと MyISAM ストレージエンジンのいずれかを選択する代わりに、現在は TempTable と InnoDB ストレージエンジンのいずれかを選択します。

TempTable ストレージエンジンを使用すると、特定のデータの処理方法について追加の選択を行うことができます。影響を受けるデータは、DB インスタンスのすべての内部テンポラリテーブルを保持するメモリプールをオーバーフローします。

これらの選択は、大量のテンポラリデータを生成するクエリのパフォーマンスに影響します。例えば、ラージ テーブルの GROUP BY のような集約を実行している場合などです。

ヒント

ワークロードに内部テンポラリテーブルを生成するクエリが含まれている場合は、ベンチマークを実行し、パフォーマンス関連のメトリックをモニタリングして、この変更によるアプリケーションの動作を確認します。

場合によっては、テンポラリデータ量は TempTable メモリプールに収まるか、または少量だけメモリプールから溢れまする。このような場合は、内部テンポラリテーブルおよびメモリマップファイルの TempTable 設定を使用して、オーバーフローデータを保持することをお勧めします。この設定はデフォルトです。

多量のテンポラリデータが TempTable メモリプールをオーバーフローした場合、内部テンポラリテーブルの MEMORY ストレージエンジンを代わりに使用することをお勧めします。または、内部テンポラリテーブルと InnoDB テーブルの TempTable を選択して、オーバーフローデータを保持します。

初期は、TempTableストレージエンジンか MEMORY ストレージエンジンかのいずれかを 内部テンポラリテーブルに選択します。これは internal_tmp_mem_storage_engine パラメータを設定して行います。このパラメータは、Aurora MySQL バージョン 1 および 2 で使用される internal_tmp_disk_storage_engine パラメータを置き換えます。

TempTable ストレージエンジンがデフォルトです。TempTable は、テーブルあたりの最大メモリ制限ではなく、このエンジンを使うすべてのテンポラリテーブルの共通メモリプールを使用します。このメモリプールのサイズは、temptable_max_ram パラメータで特定されます。16 GB 以上のメモリを持つ DB インスタンスでは 1 GB、メモリが 16 GB 未満の DB インスタンスでは 16 MB がデフォルトになります。メモリプールのサイズは、セッションレベルのメモリ消費に影響します。

TempTable ストレージエンジンを使用しており、なおかつテンポラリデータがメモリプールのサイズを超えている場合、Aurora MySQL はセカンダリメカニズムを使ってオーバーフローデータを格納します。

パラメータ temptable_use_mmaptemptable_max_mmap を設定して、メモリマップテテンポラリファイルまたはディスク上の InnoDB 内部テンポラリテーブルのどちらにデータがオーバーフローするか、指定することができます。これらのオーバーフローメカニズムの異なるデータ形式とオーバーフロー基準は、クエリのパフォーマンスに影響を与える可能性があります。例えば、ディスクに書き込まれるデータ量や、ディスクストレージのスループットに対する要求に影響します。

Aurora MySQL は、データオーバーフローの送信先の選択、およびクエリがライターまたはリーダー DB インスタンスのどちらで実行されるかによって、オーバーフローデータを異なる方法で格納します。

  • ライターインスタンスでは、InnoDB 内部テンポラリテーブルにオーバーフローするデータは Aurora クラスター ボリュームに格納されます。

  • ライターインスタンスでは、メモリマップされたテンポラリファイルにオーバーフローするデータは、Aurora MySQL バージョン 3 インスタンスのローカルストレージに存在します。

  • リーダーインスタンスでは、オーバーフローデータは常にローカルストレージ上のメモリマップテンポラリファイルに存在します。これは、読み取り専用インスタンスでは Aurora クラスターボリュームにデータを保存できないためです。

注記

内部テンポラリテーブルに関連する構成パラメータは、クラスター内のライターインスタンスとリーダーインスタンスに対して異なる方法で適用されます。リーダーインスタンスの場合、Aurora MySQL は常にTempTable ストレージエンジンと temptable_use_mmap の 値 1 を使用します。temptable_max_mmap のデフォルトサイズは、DB インスタンスのメモリサイズに関係なく、ライターインスタンスとリーダーインスタンスの両方で 1 GB です。この値は、ライターインスタンスと同じ方法で調整できます。ただし、リーダーインスタンス上では temptable_max_mmap に対して0 の値を指定することができません。

Aurora MySQL バージョン 3 でのテンポラリテーブルのストレージ側面とパフォーマンスへの影響の詳細については、ブログ記事「Use the TempTable storage engine on Amazon RDS for MySQL and Amazon Aurora MySQL」(Amazon RDS for MySQL および Amazon Aurora MySQL の TempTable ストレージエンジンを使用する) を参照してください。

バイナリログレプリケーション

MySQL 8.0 コミュニティエディションでは、バイナリログのレプリケーションがデフォルトで有効になっています。Aurora MySQL バージョン 3 では、バイナリログレプリケーションはデフォルトで無効になっています。

ヒント

Aurora 組み込みレプリケーション機能によって高可用性要件が満たされている場合は、バイナリログレプリケーションをオフにしておくことができます。これにより、バイナリログレプリケーションのパフォーマンスオーバーヘッドを回避できます。また、バイナリログレプリケーションの管理に必要な、関連するモニタリングおよびトラブルシューティングを回避することもできます。

Aurora は MySQL 5.7 互換出典から Aurora MySQL バージョン 3 へのバイナリログレプリケーションをサポートしています。出典システムは、Aurora MySQL DB クラスター、RDS for MySQL DB インスタンス、またはオンプレミス MySQL インスタンスです。

コミュニティ MySQL と同様に、Aurora MySQL は特定のバージョンを実行している出典から、同じメジャーバージョンまたは 1 つ以上のメジャーバージョンを実行するターゲットへのレプリケーションをサポートします。例えば、MySQL 5.6 互換システムから Aurora MySQL バージョン 3 へのレプリケーションはサポートされていません。Aurora MySQL バージョン 3 から MySQL 5.7 互換または MySQL 5.6 互換システムへのレプリケーションはサポートされていません。バイナリログのレプリケーションの詳細については、Aurora と MySQL との間、または Aurora と別の Aurora DB クラスターとの間のレプリケーション (バイナリログレプリケーション) を参照してください。

Aurora MySQL バージョン 3 には、フィルタリングされたレプリケーションなど、コミュニティ MySQL 8.0 でのバイナリログレプリケーションの改善が含まれています。コミュニティ MySQL 8.0 の改善の詳細については、MySQL リファレンスマニュアルサーバがレプリケーションフィルタ規則を評価する方法を参照してください。

マルチスレッドレプリケーション

Aurora MySQL バージョン 3 では、Aurora MySQL はマルチスレッドレプリケーションをサポートします。使用に関する情報については、「マルチスレッドバイナリログレプリケーション (Aurora MySQL バージョン 3 以降)」を参照してください。

注記

Aurora MySQL バージョン 1 およびバージョン 2 では、マルチスレッドレプリケーションを使用しないことをお勧めします。

バイナリログレプリケーションのトランザクション圧縮

バイナリログ圧縮の使用方法については、MySQL リファレンスマニュアルのバイナリログトランザクションの圧縮を参照してください。

Aurora MySQL バージョン 3 のバイナリログ圧縮には、次の制限が適用されます。

  • バイナリログデータが最大許容パケットサイズより大きいトランザクションは、Aurora MySQL バイナリログ圧縮設定が有効になっているかどうかにかかわらず、圧縮されません。このようなトランザクションは、圧縮されずに複製されます。

  • MySQL 8.0 をまだサポートしていない変更データキャプチャ (CDC) にコネクタを使用している場合、この特徴は使用できません。サードパーティーのコネクタをバイナリログ圧縮でしっかりテストした後に、CDC の binlog レプリケーションを使用するシステムでバイナリログ圧縮を有効にすることをお勧めします。

Aurora MySQL バージョン 3 とコミュニティ MySQL 8.0 の比較

次の情報を使用して、別の MySQL 8.0 互換システムから Aurora MySQL バージョン 3 に変換する際の、注意すべき変更について知ることができます。

一般に、Aurora MySQL バージョン 3 はコミュニティ MySQL 8.0.23 の特徴セットをサポートしています。MySQL 8.0 コミュニティエディションの一部の新機能は Aurora MySQL には適用されません。これらの機能の一部は、Aurora ストレージアーキテクチャなど Aurora の一部の側面と互換性がありません。Amazon RDS 管理サービスで同等の機能が提供されるため、その他の機能は必要ありません。コミュニティ MySQL 8.0 の次の機能は、Aurora MySQL バージョン 3 でサポートされていない、あるいは異なる動作をします。

すべての Aurora MySQL バージョン 3 リリースのリリースノートについては、Aurora MySQL のリリースノートの「Amazon Aurora MySQL バージョン 3 のデータベースエンジンの更新」を参照してください。

MySQL 8.0 の機能はAurora MySQL バージョン 3 では利用できません

コミュニティ MySQL 8.0 の次の機能は、Aurora MySQL バージョン 3 では利用できないか、異なる動作をします。

  • リソースグループと関連付けられた SQL ステートメントは、Aurora MySQL ではサポートされていません。

  • Aurora ストレージアーキテクチャは、データベースのファイルと基礎となるストレージを手動で管理する必要がないことを意味します。特に、Auroraはコミュニティ MySQL とは異なる方法で UNDO 表領域を処理します。コミュニティ MySQL とのこの違いは、次のような結果をもたらします。

    • Aurora MySQL は名前付きテーブルスペースをサポートしていません。

    • innodb_undo_log_truncate 構成設定はオフになっており、オンにできません。Aurora には、ストレージスペースを再利用するための独自のメカニズムがあります。

    • Aurora MySQL には CREATE UNDO TABLESPACEALTER UNDO TABLESPACE ... SET INACTIVE、および DROP UNDO TABLESPACE ステートメントがありません。

    • Aurora は、UNDO テーブルスペースの数を自動的に設定し、それらのテーブルスペースを自動的に管理します。

  • TLS 1.3 は、Aurora MySQL バージョン 3 でサポートされていません。

  • aurora_hot_page_contention ステータス可変は使用できません。ホットページの競合特徴はサポートされていません。Aurora MySQL バージョン 3 では利用できないステータス可変の完全なリストについては、ステータス可変 を参照してください。

  • MySQL プラグインの設定は変更できません。

  • X プラグインはサポートされていません。

ロールベースの特権モデル

Aurora MySQL バージョン 3 では、mysql データベースのテーブルを直接変更できません。特に、mysql.user テーブルへの挿入によるユーザ設定ができません。代わりに、SQL 文を使用してロールベースの権限を付与します。また、mysql データベースでストアドプロシージャなど、他の種類のオブジェクトを作成することはできません。mysql テーブルにクエリを実行することはできます。バイナリログ レプリケーションを使用する場合、出典 クラスターの mysql テーブルへの直接的な変更は、ターゲット クラスターにレプリケートされません。

場合によっては、mysql テーブルに挿入することで、アプリケーションがショートカットを使用して、ユーザーやその他のオブジェクトを作成する場合があります。その場合は、アプリケーションコードを変更して、CREATE USER などの対応したステートメントを使用します。アプリケーションが mysql データベースでストアドプロシージャまたはその他のオブジェクトを作成する場合は、代わりに別のデータベースを使用してください。

外部 MySQL データベースからの移行中にデータベースユーザーのメタデータをエクスポートするには、mysqldump の代わりに mysqlpump コマンドを使用します。以下の構文を使用します。

mysqlpump --exclude-databases=mysql --users

このステートメントは、mysql システムデータベースのテーブルを除くすべてのデータベースをダンプします。これには移行されたデータベース内のすべての MySQL ユーザーを再現する CREATE USERGRANT ステートメントも含まれます。また、出典システムの pt-show-grants ツールを使用して、すべてのデータベースユーザーを再現するCREATE USERGRANT ステートメントをリスト化することも可能です。

多くのユーザーまたはアプリケーションの権限の管理を簡素化するには、CREATE ROLE ステートメントを使用して、一連の権限を持つロールを作成します。その後、GRANT および SET ROLE ステートメントと current_role 関数を使用して、ユーザーまたはアプリケーションにロールを割り当てたり、現在のロールを切り替えたり、有効なロールをチェックしたりできます。MySQL 8.0 でのロールベースのアクセス許可システムの詳細については、MySQL リファレンスマニュアルのロールの使用を参照してください。

Aurora MySQL バージョン 3 には、以下のすべての権限を持つ特別なロールが含まれています。ロールの名前は rds_superuser_role です。各クラスターのプライマリ管理ユーザーには、既にこのロールが付与されています。rds_superuser_role ロールには、すべてのデータベースオブジェクトに対する次の権限が含まれます。

  • ALTER

  • APPLICATION_PASSWORD_ADMIN

  • ALTER ROUTINE

  • CONNECTION_ADMIN

  • CREATE

  • CREATE ROLE

  • CREATE ROUTINE

  • CREATE TABLESPACE

  • CREATE TEMPORARY TABLES

  • CREATE USER

  • CREATE VIEW

  • DELETE

  • DROP

  • DROP ROLE

  • EVENT

  • EXECUTE

  • INDEX

  • INSERT

  • LOCK TABLES

  • PROCESS

  • REFERENCES

  • RELOAD

  • REPLICATION CLIENT

  • REPLICATION SLAVE

  • ROLE_ADMIN

  • SET_USER_ID

  • SELECT

  • SHOW DATABASES

  • SHOW VIEW

  • TRIGGER

  • UPDATE

  • XA_RECOVER_ADMIN

ロール定義には WITH GRANT OPTION が含まれるため、管理ユーザーはそのロールを他のユーザーに付与することができます。特に、Aurora MySQL クラスターをターゲットとしてバイナリログレプリケーションを実行するために必要な権限を、管理者は付与する必要があります。

ヒント

権限の詳細全体を表示するには、次のステートメントを入力します。

SHOW GRANTS FOR rds_superuser_role@'%'; SHOW GRANTS FOR name_of_administrative_user_for_your_cluster@'%';

Aurora MySQL バージョン 3 には、他の AWS サービスにアクセスするために使用できるロールも含まれています。これらのロールは、GRANT ステートメントの代替として設定できます。例えば、GRANT INVOKE LAMBDA ON *.* TO user の代わりに GRANT AWS_LAMBDA_ACCESS TO user を指定します。他の AWS サービスにアクセスする手順については、Amazon Aurora MySQL と他の AWS のサービスの統合 を参照してください。Aurora MySQLバージョン 3 には、他の AWS サービスへのアクセスに関連する次のロールが含まれています。

Aurora MySQL バージョン 3 でロールを使用してアクセスを許可する場合は、SET ROLE role_name または SET ROLE ALL ステートメントを使用してロールも有効化します。以下の例のように指定します。AWS_SELECT_S3_ACCESS 用に適切なロール名を置き換えます。

# Grant role to user mysql> GRANT AWS_SELECT_S3_ACCESS TO 'user'@'domain-or-ip-address' # Check the current roles for your user. In this case, the AWS_SELECT_S3_ACCESS role has not been activated. # Only the rds_superuser_role is currently in effect. mysql> SELECT CURRENT_ROLE(); +--------------------------+ | CURRENT_ROLE() | +--------------------------+ | `rds_superuser_role`@`%` | +--------------------------+ 1 row in set (0.00 sec) # Activate all roles associated with this user using SET ROLE. # You can activate specific roles or all roles. # In this case, the user only has 2 roles, so we specify ALL. mysql> SET ROLE ALL; Query OK, 0 rows affected (0.00 sec) # Verify role is now active mysql> SELECT CURRENT_ROLE(); +--------------------------------------------------+ | CURRENT_ROLE() | +--------------------------------------------------+ | `AWS_LAMBDA_ACCESS`@`%`,`rds_superuser_role`@`%` | +--------------------------------------------------+

認証

コミュニティ MySQL 8.0 では、デフォルトの認証プラグインは caching_sha2_password です。Aurora MySQL バージョン3では、mysql_native_password プラグインがまだ使用されます。default_authentication_plugin 設定は変更できません。

Aurora MySQL バージョン 3 へのアップグレード

Aurora MySQL バージョン 1 または 2 からバージョン 3 にデータベースをアップグレードするための特定のアップグレードパスについては、次のいずれかの方法を使用できます。

  • Aurora MySQL バージョン 2 クラスターをバージョン 3 にアップグレードするには、バージョン 2 クラスターのスナップショットを作成し、スナップショットを復元して新しいバージョン 3 クラスターを作成します。「DB クラスターのスナップショットからの復元」の手順に従います。現在、Aurora MySQL バージョン 2 から Aurora MySQL バージョン 3 へのインプレースアップグレードは利用できません。

  • Aurora MySQL バージョン 1 からアップグレードするには、まず Aurora MySQL バージョン 2 への中間アップグレードを実行します。Aurora MySQL バージョン 2 へのアップグレードを行うには、Amazon Aurora MySQL DB クラスターのアップグレード のいずれかのアップグレード方法を使用します。次に、スナップショットの復元手法を使用して Aurora MySQL バージョン 2 から Aurora MySQL バージョン 3 にアップグレードします。Aurora MySQL バージョン 1 クラスタ (MySQL 5.6 との互換性) から Aurora MySQL バージョン 3 へのスナップショットの復元は使用できません。

  • 現在、MySQL 5.7 互換 Aurora クラスターを MySQL 8.0 互換クラスターにクローンすることはできません。代わりに、スナップショット リストア手法を使用してください。

  • バックトラックを使用する Aurora MySQL バージョン 2 クラスターがある場合、スナップショットの復元方法を使用して Aurora MySQL バージョン 3 にアップグレードすることは現状できません。この制限は、バックトラック設定が有効になっているかどうかにかかわらず、バックトラックを使用するすべてのクラスタに適用されます。この場合、mysqldump のようなツールを使用して、論理的なダンプと復元を実行します。Aurora MySQL の mysqldump の使用の詳細については、mysqldump を使用した MySQL から Amazon Aurora への移行 を参照してください。

ヒント

場合によっては、スナップショットを復元するときに CloudWatch にデータベースログをアップロードするオプションを指定することがあります。その場合は CloudWatch のログを調べて、復元、および関連するアップグレードの操作中に発生する問題を診断します。このセクションの CLI 例では、--enable-cloudwatch-logs-exports を使用してこれを行う方法を示しています。

Aurora MySQL バージョン 3 のアップグレード計画

アップグレードの適切な時期とアプローチを決定するために、Aurora MySQL バージョン 3 と現在の Aurora および MySQL 環境の違いについて学べます。

  • MySQL 8.0 の RDS またはコミュニティ MySQL 8.0 から変換する場合は、Aurora MySQL バージョン 3 とコミュニティ MySQL 8.0 の比較 を参照してください。

  • Aurora MySQL バージョン 2、MySQL 5.7 の RDS、またはコミュニティ MySQL 5.7 からアップグレードする場合は、Aurora MySQL バージョン 2 と Aurora MySQL バージョン 3 の比較 を参照してください。

  • カスタムパラメータグループの新しい MySQL 8.0 互換バージョンを作成します。必要なカスタムパラメータ値を新しいパラメータグループに適用します。Aurora MySQL バージョン 3 のパラメータ変更 に相談して、パラメータの変更について学びます。

    注記

    ほとんどのパラメータ設定では、クラスタの作成時にカスタム パラメータグループを選択するか、後でパラメータグループをクラスターに関連付けることができます。ただし、デフォルト以外の設定を lower_case_table_names パラメータに使用する場合は、事前にこの設定を使用してカスタム パラメータグループを設定する必要があります。その後、スナップショット復元を実行してクラスターを作成する際、パラメータグループを指定します。クラスター作成後のlower_case_table_names パラメータへの変更は、影響がありません。

MySQL 固有のアップグレードに関する考慮事項とヒントについては、MySQL リファレンスマニュアルMySQL 8.0 での変更を参照してください。例えば、コマンド mysqlcheck --check-upgrade を使用して、既存の Aurora MySQL データベースを分析し、潜在的なアップグレードの問題を特定します。

以前の Aurora MySQL バージョンから Aurora MySQL バージョン 3 へアップグレードする、現状の主要経路は、スナップショットを復元して新しいクラスターを作成することです。Aurora MySQL バージョン 2 (MySQL 5.7 との互換性) のマイナーバージョンを実行しているクラスターのスナップショットを Aurora MySQL バージョン 3 に復元できます。Aurora MySQL バージョン 1 からアップグレードするには、2 段階のプロセスを使用します。まず Aurora MySQL バージョン 2 クラスターにスナップショットを復元し、そのクラスターのスナップショットを作成し、Aurora MySQL バージョン 3 クラスターに復元します。Aurora MySQL バージョン 1 または 2 からのアップグレード手順については、Aurora MySQL バージョン 3 へのアップグレード を参照してください。スナップショットを復元することによるアップグレードに関する一般情報は、Amazon Aurora MySQL DB クラスターのアップグレード を参照してください。

アップグレード自体を完了したら、「Aurora MySQL バージョン 3 のアップグレード後のクリーンアップ」のアップグレード後の手順に従います。最後に、アプリケーションの機能とパフォーマンスをテストします。

MySQL またはコミュニティ MySQL の RDS から変換する場合は、Amazon Aurora MySQL DB クラスターへのデータの移行 で説明されている移行手順に従ってください。場合によっては、バイナリログレプリケーションを使用して、移行の一環として Aurora MySQL バージョン 3 クラスターとデータを同期することがあります。その場合、出典システムは MySQL 5.7 と互換性のあるバージョン、または 8.0.23 以下のMySQL 8.0 互換バージョンを実行する必要があります。

Aurora MySQL バージョン 2 からバージョン 3 へのアップグレードの例

以下の AWS CLI 例は、Aurora MySQL バージョン 2 クラスターを Aurora MySQL バージョン 3 にアップグレードするステップを示します。

初期のステップは、アップグレードするクラスターのバージョンを特定することです。以下の AWS CLI コマンドは、その方法を示しています。出力では、元のクラスターが Aurora MySQL バージョン 2.09.2 を実行している MySQL 5.7 互換のクラスターであることが確認されます。

このクラスターには、少なくとも 1 つの DB インスタンスがあります。アップグレードプロセスが適切に機能するためには、この元のクラスターにはライターインスタンスが必要です。

$ aws rds describe-db-clusters --db-cluster-id cluster-57-upgrade-ok \ --query '*[].EngineVersion' --output text 5.7.mysql_aurora.2.09.2

次のコマンドは、特定のバージョンから使用可能なアップグレードパスをチェックする方法を示しています。この場合、元のクラスターはバージョン 5.7.mysql_aurora.2.09.2 を実行しています。出力は、このバージョンを Aurora MySQL バージョン 3 にアップグレードできることを示しています。

元のクラスターで、Aurora MySQL バージョン 3 にアップグレードするには低すぎるバージョン番号を使用している場合、アップグレードには追加のステップが必要です。まずスナップショットを復元して、Aurora MySQL バージョン 3 にアップグレードできる新しいクラスターを作成します。次に、その中間クラスターのスナップショットを作成します。最後に、中間クラスターのスナップショットを復元して、新しい Aurora MySQL バージョン 3 クラスターを作成します。

$ aws rds describe-db-engine-versions --engine aurora-mysql \ --engine-version 5.7.mysql_aurora.2.09.2 \ --query 'DBEngineVersions[].ValidUpgradeTarget[].EngineVersion' [ "5.7.mysql_aurora.2.10.0", "5.7.mysql_aurora.2.10.1", "8.0.mysql_aurora.3.01.0" ]

次のコマンドは、Aurora MySQL バージョン 3 にアップグレードするクラスターのスナップショットを作成します。元のクラスターはそのまま残ります。後で、スナップショットから新しい Aurora MySQL バージョン 3 クラスターを作成します。

aws rds create-db-cluster-snapshot --db-cluster-id cluster-57-upgrade-ok \ --db-cluster-snapshot-id cluster-57-upgrade-ok-snapshot { "DBClusterSnapshotIdentifier": "cluster-57-upgrade-ok-snapshot", "DBClusterIdentifier": "cluster-57-upgrade-ok", "SnapshotCreateTime": "2021-10-06T23:20:18.087000+00:00" }

次のコマンドは、Aurora MySQL バージョン 3 を実行している新しいクラスターにスナップショットを復元します。

$ aws rds restore-db-cluster-from-snapshot \ --snapshot-id cluster-57-upgrade-ok-snapshot \ --db-cluster-id cluster-80-restored --engine aurora-mysql \ --engine-version 8.0.mysql_aurora.3.01.0 \ --enable-cloudwatch-logs-exports '["error","general","slowquery","audit"]' { "DBClusterIdentifier": "cluster-80-restored", "Engine": "aurora-mysql", "EngineVersion": "8.0.mysql_aurora.3.01.0", "Status": "creating" }

スナップショットを復元すると、クラスターのストレージがセットアップされ、クラスターが使用できるデータベースのバージョンが確立されます。クラスターのコンピューティング性能はストレージから分離されているため、クラスター自体が作成されたら、クラスターの DB インスタンスをセットアップします。次の例では、いずれかの db.r5 インスタンスクラスを使用してライター DB インスタンスを作成します。

ヒント

db.r3、db.r4、db.t2、db.t3 などの古いインスタンスクラスを使用して DB インスタンスを作成する管理スクリプトがある場合があります。その場合は、Aurora MySQL バージョン 3 でサポートされているインスタンスクラスの 1 つを使用するようにスクリプトを変更します。Aurora MySQL バージョン 3 で使用できるインスタンスクラスの詳細については、インスタンスクラスのサポート を参照してください。

$ aws rds create-db-instance --db-instance-identifier instance-running-version-3 \ --db-cluster-identifier cluster-80-restored \ --db-instance-class db.r5.xlarge --engine aurora-mysql { "DBInstanceIdentifier": "instance-running-version-3", "DBClusterIdentifier": "cluster-80-restored", "DBInstanceClass": "db.r5.xlarge", "EngineVersion": "8.0.mysql_aurora.3.01.0", "DBInstanceStatus": "creating" }

アップグレードが完了したら、AWS CLI を使用して Aurora 固有のクラスターのバージョン番号を確認できます。

$ aws rds describe-db-clusters --db-cluster-id cluster-80-restored \ --query '*[].EngineVersion' --output text 8.0.mysql_aurora.3.01.0

また、データベースエンジンの MySQL 固有のバージョンを確認するには、version 関数を呼び出します。

mysql> select version(); +-----------+ | version() | +-----------+ | 8.0.23 | +-----------+

Aurora MySQL バージョン 1 からバージョン 3 へのアップグレードの例

次の例は、元のスナップショットが Aurora MySQL バージョン 3 に直接復元できないバージョンの場合の 2 段階アップグレードプロセスを示しています。代わりにそのスナップショットは、Aurora MySQL バージョン 3 にアップグレードできる中間バージョンを実行しているクラスターに復元されます。この中間クラスターには、関連付けられた DB インスタンスは必要ありません。次に、中間クラスターから別のスナップショットが作成されます。最後に、2 番目のスナップショットが復元され、新しい Aurora MySQL バージョン 3 クラスターとライター DB インスタンスが作成されます。

初期に使用スタートする Aurora MySQL バージョン 1 クラスターは、aurora-mysql-v1-to-v2 と名付けられています。Aurora MySQL バージョン 1.23.4 を実行しています。クラスター内に少なくとも 1 つの DB インスタンスがあります。

この例では、Aurora MySQL バージョン 2 のどのバージョンを 8.0.mysql_aurora.3.01.0 にアップグレードして、アップグレードされたクラスター上で使用できるかチェックします。この例では、中間バージョンとしてバージョン 2.10.0 を選択します。

$ aws rds describe-db-engine-versions --engine aurora-mysql \ --query '*[].{EngineVersion:EngineVersion,TargetVersions:ValidUpgradeTarget[*].EngineVersion} | [?contains(TargetVersions, `'8.0.mysql_aurora.3.01.0'`) == `true`]|[].EngineVersion' \ --output text ... 5.7.mysql_aurora.2.08.3 5.7.mysql_aurora.2.09.1 5.7.mysql_aurora.2.09.2 5.7.mysql_aurora.2.10.0 ...

次の例では、Aurora MySQL バージョン 1.23.4 から 2.10.0 が利用可能なアップグレードパスであることを確認します。したがって、実行している Aurora MySQL バージョンは 2.10.0 にアップグレードできます。その後、そのクラスターを 3.01.0 にアップグレードできます。

aws rds describe-db-engine-versions --engine aurora \ --query '*[].{EngineVersion:EngineVersion,TargetVersions:ValidUpgradeTarget[*].EngineVersion} | [?contains(TargetVersions, `'5.7.mysql_aurora.2.10.0'`) == `true`]|[].[EngineVersion]' \ --output text ... 5.6.mysql_aurora.1.22.5 5.6.mysql_aurora.1.23.0 5.6.mysql_aurora.1.23.1 5.6.mysql_aurora.1.23.2 5.6.mysql_aurora.1.23.3 5.6.mysql_aurora.1.23.4 ...

次の例では、aurora-mysql-v1-to-v2-snapshot という名前のスナップショットを作成します。これは元の Aurora MySQL バージョン 1 クラスターに基づいています。

$ aws rds create-db-cluster-snapshot \ --db-cluster-id aurora-mysql-v1-to-v2 \ --db-cluster-snapshot-id aurora-mysql-v1-to-v2-snapshot { "DBClusterSnapshotIdentifier": "aurora-mysql-v1-to-v2-snapshot", "DBClusterIdentifier": "aurora-mysql-v1-to-v2" }

次の例では、バージョン 1 のスナップショットから中間 Aurora MySQL バージョン 2 クラスターを作成します。この中間クラスターには aurora-mysql-v2-to-v3 という名前が付けられています。Aurora MySQL バージョン 2.10.0 を実行しています。

この例では、クラスターのライターインスタンスも作成します。アップグレードプロセスが適切に機能するためには、この中間クラスターにはライターインスタンスが必要です。

$ aws rds restore-db-cluster-from-snapshot \ --snapshot-id aurora-mysql-v1-to-v2-snapshot \ --db-cluster-id aurora-mysql-v2-to-v3 \ --engine aurora-mysql --engine-version 5.7.mysql_aurora.2.10.0 \ --enable-cloudwatch-logs-exports '["error","general","slowquery","audit"]' { "DBCluster": { "AllocatedStorage": 1, "AvailabilityZones": [ "us-east-1a", "us-east-1d", "us-east-1f" ], ... $ aws rds create-db-instance --db-instance-identifier upgrade-demo-instance \ --db-cluster-identifier aurora-mysql-v2-to-v3 \ --db-instance-class db.r5.xlarge \ --engine aurora-mysql { "DBInstanceIdentifier": "upgrade-demo-instance", "DBInstanceClass": "db.r5.xlarge", "DBInstanceStatus": "creating" }

次の例では、中間 Aurora MySQL バージョン 2 クラスターからスナップショットを作成します。このスナップショットにはaurora-mysql-v2-to-v3-snapshot という名前が付けられています。これは、Aurora MySQL バージョン 3 クラスターを作成するために復元されるスナップショットです。

$ aws rds create-db-cluster-snapshot \ --db-cluster-id aurora-mysql-v2-to-v3 \ --db-cluster-snapshot-id aurora-mysql-v2-to-v3-snapshot { "DBClusterSnapshotIdentifier": "aurora-mysql-v2-to-v3-snapshot", "DBClusterIdentifier": "aurora-mysql-v2-to-v3" }

次のコマンドは、Aurora MySQL バージョン 3 クラスターを作成します。クラスターは aurora-mysql-v3-fully-upgraded と名付けられています。

$ aws rds restore-db-cluster-from-snapshot \ --snapshot-id aurora-mysql-v2-to-v3-snapshot \ --db-cluster-id aurora-mysql-v3-fully-upgraded \ --engine aurora-mysql --engine-version 8.0.mysql_aurora.3.01.0 \ --enable-cloudwatch-logs-exports '["error","general","slowquery","audit"]' { "DBCluster": { "AllocatedStorage": 1, "AvailabilityZones": [ "us-east-1b", "us-east-1c", "us-east-1d" ], ...

Aurora MySQL バージョン 3 クラスターが作成されたので、次の例では、そのクラスターのライター DB インスタンスを作成します。クラスターとライターインスタンスが利用可能になったら、クラスターに接続して使用をスタートできます。元のクラスターのすべてのデータは、スナップショットステージごとに保持されます。

$ aws rds create-db-instance \ --db-instance-identifier instance-also-running-v3 \ --db-cluster-identifier aurora-mysql-v3-fully-upgraded \ --db-instance-class db.r5.xlarge --engine aurora-mysql { "DBInstanceIdentifier": "instance-also-running-v3", "DBClusterIdentifier": "aurora-mysql-v3-fully-upgraded", "DBInstanceClass": "db.r5.xlarge", "EngineVersion": "8.0.mysql_aurora.3.01.0", "DBInstanceStatus": "creating" }

Aurora MySQL バージョン 3 のアップグレードに関する問題のトラブルシューティング

Aurora MySQL で、バージョン 3 へのアップグレードが正常に完了しない場合は、問題の原因を診断します。その後、元のデータベーススキーマまたはテーブルデータに必要な変更を加えて、アップグレードプロセスを再度実行できます。

Aurora MySQL バージョン 3 へのアップグレードプロセスが失敗した場合、復元されたスナップショットのライターインスタンスの作成およびアップグレード中に問題が発生しています。Aurora は 5.7 互換のライターインスタンス変更しません。これにより、アップグレードを実行する前に Aurora が実行する予備チェックに関するログを調べることができます。以下の例では、Aurora MySQL バージョン 3 にアップグレードする前にいくつかの変更が必要な、5.7 互換データベースを最初に処理しています。この例は、最初に試行されたアップグレードがどのように失敗するか、ログファイルを調べる方法、および問題を解決して正常にアップグレードを完了する方法を示しています。

まず、problematic-57-80-upgrade という名前の新しい MySQL 5.7 互換クラスターを作成します。この名前が示すように、このクラスターには MySQL 8.0 互換バージョンへのアップグレード中に問題を引き起こすスキーマオブジェクトが、少なくとも 1 つ含まれています。

$ aws rds create-db-cluster --engine aurora-mysql \ --engine-version 5.7.mysql_aurora.2.10.0 \ --db-cluster-identifier problematic-57-80-upgrade \ --master-username my_username \ --master-user-password my_password { "DBClusterIdentifier": "problematic-57-80-upgrade", "Status": "creating" } $ aws rds create-db-instance \ --db-instance-identifier instance-preupgrade \ --db-cluster-identifier problematic-57-80-upgrade \ --db-instance-class db.t2.small --engine aurora-mysql { "DBInstanceIdentifier": "instance-preupgrade", "DBClusterIdentifier": "problematic-57-80-upgrade", "DBInstanceClass": "db.t2.small", "DBInstanceStatus": "creating" } $ aws rds wait db-instance-available \ --db-instance-identifier instance-preupgrade

ここでアップグレードするクラスターには、問題のあるテーブルが含まれています。FULLTEXT インデックスを作成し後にそのインデックスを削除すると、メタデータが残され、アップグレード中に問題を引き起こします。

$ mysql -u my_username -p \ -h problematic-57-80-upgrade.cluster-example123.us-east-1.rds.amazonaws.com mysql> create database problematic_upgrade; Query OK, 1 row affected (0.02 sec) mysql> use problematic_upgrade; Database changed mysql> CREATE TABLE dangling_fulltext_index -> (id INT AUTO_INCREMENT PRIMARY KEY, txtcol TEXT NOT NULL) -> ENGINE=InnoDB; Query OK, 0 rows affected (0.05 sec) mysql> ALTER TABLE dangling_fulltext_index ADD FULLTEXT(txtcol); Query OK, 0 rows affected, 1 warning (0.14 sec) mysql> ALTER TABLE dangling_fulltext_index DROP INDEX txtcol; Query OK, 0 rows affected (0.06 sec)

この例では、アップグレード手順の実行を試みます。元のクラスターのスナップショットを作成し、その処理が完了するのを待ちます。次に、MySQL 8.0 互換のバージョン番号を指定して、スナップショットを復元します。また、クラスターのライターインスタンスも作成します。これは、アップグレード処理が実際に行われるポイントです。その後、インスタンスが利用可能になるのを待ちます。これは、結果が成功か失敗かにかかわらず、アップグレードプロセスが終了するポイントです。

ヒント

AWS Management Console を使用してスナップショットを復元する場合、Aurora はライターインスタンスを自動的に作成し、それをリクエストされたエンジンバージョンにアップグレードします。

$ aws rds create-db-cluster-snapshot --db-cluster-id problematic-57-80-upgrade \ --db-cluster-snapshot-id problematic-57-80-upgrade-snapshot { "DBClusterSnapshotIdentifier": "problematic-57-80-upgrade-snapshot", "DBClusterIdentifier": "problematic-57-80-upgrade", "Engine": "aurora-mysql", "EngineVersion": "5.7.mysql_aurora.2.10.0" } $ aws rds wait db-cluster-snapshot-available \ --db-cluster-snapshot-id problematic-57-80-upgrade-snapshot $ aws rds restore-db-cluster-from-snapshot \ --snapshot-id problematic-57-80-upgrade-snapshot \ --db-cluster-id cluster-80-attempt-1 --engine aurora-mysql \ --engine-version 8.0.mysql_aurora.3.01.0 \ --enable-cloudwatch-logs-exports '["error","general","slowquery","audit"]' { "DBClusterIdentifier": "cluster-80-attempt-1", "Engine": "aurora-mysql", "EngineVersion": "8.0.mysql_aurora.3.01.0", "Status": "creating" } $ aws rds create-db-instance --db-instance-identifier instance-attempt-1 \ --db-cluster-identifier cluster-80-attempt-1 \ --db-instance-class db.r5.xlarge --engine aurora-mysql { "DBInstanceIdentifier": "instance-attempt-1", "DBClusterIdentifier": "cluster-80-attempt-1", "DBInstanceClass": "db.r5.xlarge", "EngineVersion": "8.0.mysql_aurora.3.01.0", "DBInstanceStatus": "creating" } $ aws rds wait db-instance-available \ --db-instance-identifier instance-attempt-1

この段階で、新しく作成されたクラスターと関連付けられたインスタンスを調べ、アップグレードが成功したかどうかを確認します。依然として、クラスターとインスタンスは MySQL 5.7 互換のバージョンを実行しています。つまり、アップグレードが失敗したことを意味します。アップグレードが失敗した場合、Aurora はライターインスタンスのみを残すので、ユーザーはログファイルを調べることができます。新しく作成されたクラスターでは、アップグレードプロセスを再起動することはできません。元のクラスターを変更して問題を修正したら、アップグレードのステップを再度実行する必要があります。元のクラスターの新しいスナップショットを作成し、別の MySQL 8.0 互換クラスターに復元します。

$ aws rds describe-db-clusters \ --db-cluster-identifier cluster-80-attempt-1 \ --query '*[].[Status]' --output text available $ aws rds describe-db-clusters \ --db-cluster-identifier cluster-80-attempt-1 \ --query '*[].[EngineVersion]' --output text 5.7.mysql_aurora.2.10.0 $ aws rds describe-db-instances \ --db-instance-identifier instance-attempt-1 \ --query '*[].{DBInstanceStatus:DBInstanceStatus}' --output text available $ aws rds describe-db-instances \ --db-instance-identifier instance-attempt-1 \ --query '*[].[EngineVersion]' --output text 5.7.mysql_aurora.2.10.0

アップグレードプロセス中に起きた事象の概要を取得するには、新しく作成されたライターインスタンスのイベントのリストを取得します。この例では、アップグレードプロセスの全時間をカバーするために、過去 600 分間のイベントを一覧表示します。リストに表示されるイベントは必ずしも時系列順にあるとは限りません。強調表示されたイベントにより、クラスターをアップグレードできない問題が発生したことを確認できます。

$ aws rds describe-events \ --source-identifier instance-attempt-1 --source-type db-instance \ --duration 600 { "Events": [ { "SourceIdentifier": "instance-attempt-1", "SourceType": "db-instance", "Message": "Binlog position from crash recovery is mysql-bin-changelog.000001 154", "EventCategories": [], "Date": "2021-12-03T20:26:17.862000+00:00", "SourceArn": "arn:aws:rds:us-east-1:123456789012:db:instance-attempt-1" }, { "SourceIdentifier": "instance-attempt-1", "SourceType": "db-instance", "Message": "Database cluster is in a state that cannot be upgraded: PreUpgrade checks failed: Oscar PreChecker Found 1 errors", "EventCategories": [ "maintenance" ], "Date": "2021-12-03T20:26:50.436000+00:00", "SourceArn": "arn:aws:rds:us-east-1:123456789012:db:instance-attempt-1" }, { "SourceIdentifier": "instance-attempt-1", "SourceType": "db-instance", "Message": "DB instance created", "EventCategories": [ "creation" ], "Date": "2021-12-03T20:26:58.830000+00:00", "SourceArn": "arn:aws:rds:us-east-1:123456789012:db:instance-attempt-1" }, ...

問題の正確な原因を診断するには、新しく作成されたライターインスタンスのデータベースログを調べます。8.0 互換バージョンへのアップグレードが失敗した場合には、インスタンスに、upgrade-prechecks.log というファイル名のログファイルが含まれます。この例では、そのログの存在を検出し、それを調査のためにローカルファイルにダウンロードする方法を示します。

$ aws rds describe-db-log-files --db-instance-identifier instance-attempt-1 \ --query '*[].[LogFileName]' --output text error/mysql-error-running.log error/mysql-error-running.log.2021-12-03.20 error/mysql-error-running.log.2021-12-03.21 error/mysql-error.log external/mysql-external.log upgrade-prechecks.log $ aws rds download-db-log-file-portion --db-instance-identifier instance-attempt-1 \ --log-file-name upgrade-prechecks.log --starting-token 0 \ --output text >upgrade_prechecks.log

この upgrade-prechecks.log ファイルは JSON 形式です。別の JSON ラッパー内で JSON 出力がエンコードされないように、--output text オプションを使用してこのファイルをダウンロードします Aurora MySQL バージョン 3 のアップグレードでは、このログには常に、特定の情報と警告メッセージが含まれます。エラーメッセージは、アップグレードが失敗した場合にのみ含まれます。アップグレードが成功すると、ログファイルはまったく生成されません。次の抜粋では、検索で見つかるエントリの種類を示しています。

$ cat upgrade-prechecks.log { "serverAddress": "/tmp%2Fmysql.sock", "serverVersion": "5.7.12", "targetVersion": "8.0.23", "auroraServerVersion": "2.10.0", "auroraTargetVersion": "3.01.0", "outfilePath": "/rdsdbdata/tmp/PreChecker.log", "checksPerformed": [

"detectedProblems" が空の場合は、アップグレードで対象のタイプの問題が発生していません。これらのエントリは無視して構いません。

{ "id": "oldTemporalCheck", "title": "Usage of old temporal type", "status": "OK", "detectedProblems": [] },

変数の削除、またはデフォルト値の変更に関するチェックは、自動的には実行されません。Aurora は、物理設定ファイルの代わりにパラメータグループのメカニズムを使用します。変数の変更がデータベースに影響するかどうかにかかわらず、この CONFIGURATION_ERROR を含むいくつかのメッセージが常に届きます。これらの変更の詳細については、MySQL のドキュメントを参照してください。

{ "id": "removedSysLogVars", "title": "Removed system variables for error logging to the system log configuration", "status": "CONFIGURATION_ERROR", "description": "To run this check requires full path to MySQL server configuration file to be specified at 'configPath' key of options dictionary", "documentationLink": "https://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-13.html#mysqld-8-0-13-logging" },

古い日付と時刻のデータ型に関するこの警告は、パラメータグループの SQL_MODE 設定がデフォルト値のままになっている場合に発生します。データベースには、影響を受けるタイプの列が含まれている場合と含まれていない場合があります。

{ "id": "zeroDatesCheck", "title": "Zero Date, Datetime, and Timestamp values", "status": "OK", "description": "Warning: By default zero date/datetime/timestamp values are no longer allowed in MySQL, as of 5.7.8 NO_ZERO_IN_DATE and NO_ZERO_DATE are included in SQL_MODE by default. These modes should be used with strict mode as they will be merged with strict mode in a future release. If you do not include these modes in your SQL_MODE setting, you are able to insert date/datetime/timestamp values that contain zeros. It is strongly advised to replace zero values with valid ones, as they may not work correctly in the future.", "documentationLink": "https://lefred.be/content/mysql-8-0-and-wrong-dates/", "detectedProblems": [ { "level": "Warning", "dbObject": "global.sql_mode", "description": "does not contain either NO_ZERO_DATE or NO_ZERO_IN_DATE which allows insertion of zero dates" } ] },

detectedProblemsフィールドに、Errorlevel 値を持つエントリーが含まれる場合、これらの問題を修正するまでアップグレードは成功しません。

{ "id": "getDanglingFulltextIndex", "title": "Tables with dangling FULLTEXT index reference", "status": "OK", "description": "Error: The following tables contain dangling FULLTEXT index which is not supported. It is recommended to rebuild the table before upgrade.", "detectedProblems": [ { "level": "Error", "dbObject": "problematic_upgrade.dangling_fulltext_index", "description": "Table `problematic_upgrade.dangling_fulltext_index` contains dangling FULLTEXT index. Kindly recreate the table before upgrade." } ] },
ヒント

これらのエラーの概要と、関連するオブジェクトおよび記述フィールドを表示するには、upgrade-prechecks.log ファイルに記述されている grep -A 2 '"level": "Error"' コマンドを実行します。これにより、各エラー行に続き他の 2 行が表示されます。この行には、対応するデータベースオブジェクトの名前と、問題の修正方法に関するガイダンスが含まれています。

$ cat upgrade-prechecks.log | grep -A 2 '"level": "Error"' "level": "Error", "dbObject": "problematic_upgrade.dangling_fulltext_index", "description": "Table `problematic_upgrade.dangling_fulltext_index` contains dangling FULLTEXT index. Kindly recreate the table before upgrade."

Aurora MySQL バージョン 3 へのアップグレードでは、この defaultAuthenticationPlugin チェックは常にこの警告メッセージを表示します。これは、Aurora MySQL バージョン 3 が、caching_sha2_password の代わりに mysql_native_password プラグインを使用しているためです。これに関しては、実行する必要があるアクションはありません。

{ "id": "defaultAuthenticationPlugin", "title": "New default authentication plugin considerations", "description": "Warning: The new default authentication plugin 'caching_sha2_password' offers more secure password hashing than previously used 'mysql_native_password' (and consequent improved client connection ... "documentationLink": "https://dev.mysql.com/doc/refman/8.0/en/upgrading-from-previous-series.html#upgrade-caching-sha2-password-compatibility-issues\nhttps://dev.mysql.com/doc/refman/8.0/en/upgrading-from-previous-series.html#upgrade-caching-sha2-password-replication" }

upgrade-prechecks.log ファイルでは最後に、軽微なまたは重大な問題の種類ごとに、それらが検出されたチェックの数が要約されます。errorCount がゼロ以外の場合は、アップグレードが失敗したことを示します。

], "errorCount": 1, "warningCount": 2, "noticeCount": 0, "Summary": "1 errors were found. Please correct these issues before upgrading to avoid compatibility issues." }

次の一連の例は、この特定の問題を修正し、アップグレードプロセスを再度実行する方法を示しています。今回は、アップグレードが成功します。

まず、元のクラスターに戻り、メタデータに問題があるテーブルと同じ構造と内容で、新しいテーブルを作成します。実際には、アップグレード後に、このテーブルの名前を元のテーブルの名前に戻します。

$ mysql -u my_username -p \ -h problematic-57-80-upgrade.cluster-example123.us-east-1.rds.amazonaws.com mysql> show databases; +---------------------+ | Database | +---------------------+ | information_schema | | mysql | | performance_schema | | problematic_upgrade | | sys | +---------------------+ 5 rows in set (0.00 sec) mysql> use problematic_upgrade; mysql> show tables; +-------------------------------+ | Tables_in_problematic_upgrade | +-------------------------------+ | dangling_fulltext_index | +-------------------------------+ 1 row in set (0.00 sec) mysql> desc dangling_fulltext_index; +--------+---------+------+-----+---------+----------------+ | Field | Type | Null | Key | Default | Extra | +--------+---------+------+-----+---------+----------------+ | id | int(11) | NO | PRI | NULL | auto_increment | | txtcol | text | NO | | NULL | | +--------+---------+------+-----+---------+----------------+ 2 rows in set (0.00 sec) mysql> CREATE TABLE recreated_table LIKE dangling_fulltext_index; Query OK, 0 rows affected (0.03 sec) mysql> INSERT INTO recreated_table SELECT * FROM dangling_fulltext_index; Query OK, 0 rows affected (0.00 sec) mysql> drop table dangling_fulltext_index; Query OK, 0 rows affected (0.05 sec)

この段階で、以前と同じプロセスにより、元のクラスターからスナップショットを作成し、そのスナップショットを新しい MySQL 8.0 互換クラスターに復元し、ライターインスタンスを作成してアップグレードプロセスを完了します。

$ aws rds create-db-cluster-snapshot --db-cluster-id problematic-57-80-upgrade \ --db-cluster-snapshot-id problematic-57-80-upgrade-snapshot-2 { "DBClusterSnapshotIdentifier": "problematic-57-80-upgrade-snapshot-2", "DBClusterIdentifier": "problematic-57-80-upgrade", "Engine": "aurora-mysql", "EngineVersion": "5.7.mysql_aurora.2.10.0" } $ aws rds wait db-cluster-snapshot-available \ --db-cluster-snapshot-id problematic-57-80-upgrade-snapshot-2 $ aws rds restore-db-cluster-from-snapshot \ --snapshot-id problematic-57-80-upgrade-snapshot-2 \ --db-cluster-id cluster-80-attempt-2 --engine aurora-mysql \ --engine-version 8.0.mysql_aurora.3.01.0 \ --enable-cloudwatch-logs-exports '["error","general","slowquery","audit"]' { "DBClusterIdentifier": "cluster-80-attempt-2", "Engine": "aurora-mysql", "EngineVersion": "8.0.mysql_aurora.3.01.0", "Status": "creating" } $ aws rds create-db-instance --db-instance-identifier instance-attempt-2 \ --db-cluster-identifier cluster-80-attempt-2 \ --db-instance-class db.r5.xlarge --engine aurora-mysql { "DBInstanceIdentifier": "instance-attempt-2", "DBClusterIdentifier": "cluster-80-attempt-2", "DBInstanceClass": "db.r5.xlarge", "EngineVersion": "8.0.mysql_aurora.3.01.0", "DBInstanceStatus": "creating" } $ aws rds wait db-instance-available \ --db-instance-identifier instance-attempt-2

今回は、アップグレードの完了後にバージョンを確認すると、それが Aurora MySQL バージョン 3 を反映するバージョン番号に変更されていることが確認できます。データベースに接続すると、MySQL エンジンのバージョンが 8.0 互換であることを確認できます。アップグレードされたクラスターに、元のアップグレードの問題の原因となったテーブルが、修正された形で含まれていることを確認します。

$ aws rds describe-db-clusters \ --db-cluster-identifier cluster-80-attempt-2 \ --query '*[].[EngineVersion]' --output text 8.0.mysql_aurora.3.01.0 $ aws rds describe-db-instances \ --db-instance-identifier instance-attempt-2 \ --query '*[].[EngineVersion]' --output text 8.0.mysql_aurora.3.01.0 $ mysql -h cluster-80-attempt-2.cluster-example123.us-east-1.rds.amazonaws.com \ -u my_username -p mysql> select version(); +-----------+ | version() | +-----------+ | 8.0.23 | +-----------+ 1 row in set (0.00 sec) mysql> show databases; +---------------------+ | Database | +---------------------+ | information_schema | | mysql | | performance_schema | | problematic_upgrade | | sys | +---------------------+ 5 rows in set (0.00 sec) mysql> use problematic_upgrade; Database changed mysql> show tables; +-------------------------------+ | Tables_in_problematic_upgrade | +-------------------------------+ | recreated_table | +-------------------------------+ 1 row in set (0.00 sec)

Aurora MySQL バージョン 3 のアップグレード後のクリーンアップ

Aurora MySQL バージョン 1 または 2 クラスタを Aurora MySQL バージョン 3 にアップグレードした後、次の他のクリーンアップアクションを実行できます。

  • カスタム パラメータグループの新しい MySQL 8.0 互換バージョンを作成します。必要なカスタムパラメータ値を新しいパラメータグループに適用します。

  • CloudWatch アラーム、セットアップスクリプトなどを更新して、インクルーシブな言語変更の影響を受けた名前のメトリクスに、新しい名前を使用します。このようなメトリクスの一覧は、Aurora MySQL バージョン 3 に対する包括的な言語変更 をご覧ください。

  • AWS CloudFormation テンプレートをすべて更新して、包括的な言語の変更によって影響を受けるすべてのコンフィギュレーション パラメータの名前を新しくします。そのようなパラメータのリストについては、Aurora MySQL バージョン 3 に対する包括的な言語変更 を参照してください。

空間インデックス

Aurora MySQL バージョン 3 にアップグレードした後、空間インデックスに関連するオブジェクトおよびインデックスを削除または再作成する必要があるかどうかをチェックします。MySQL 8.0 より前では、Aurora は空間リソース識別子 (SRID) を含まないインデックスを使用して空間クエリを最適化できました。Aurora MySQL バージョン 3 では、SRID を含む空間インデックスのみを使用します。アップグレード中、Aurora は SRID のない空間インデックスを自動的にドロップし、警告メッセージをデータベースログに出力します。このような警告メッセージが表示された場合は、アップグレード後に SRID を使用して新しい空間インデックスを作成します。MySQL 8.0 での空間関数とデータ型の変更の詳細については、MySQL リファレンスマニュアルMySQL 8.0 での変更を参照してください。