# 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 を必要とします。
**Topics**
+ [MySQL 8.0 コミュニティエディションからの機能](#AuroraMySQL.8.0-features-community)
+ [Aurora MySQL サーバーレス v2 の前提条件である Aurora MySQL バージョン 3](#AuroraMySQL.serverless-v2-8.0-prereq)
+ [Aurora MySQL バージョン 3 のリリースノート](#AuroraMySQL.mysql80-bugs-fixed)
+ [新しいパラレルクエリの最適化](#AuroraMySQL.8.0-features-pq)
+ [データベースの再起動時間を短縮するための最適化](#ReducedRestartTime)
+ [Aurora MySQL バージョン 3 での新しい一時テーブルの動作](ams3-temptable-behavior.md)
+ [Aurora MySQL バージョン 2 と Aurora MySQL バージョン 3 の比較](AuroraMySQL.Compare-v2-v3.md)
+ [Aurora MySQL バージョン 3 と MySQL 8.0 コミュニティエディションの比較](AuroraMySQL.Compare-80-v3.md)
+ [Aurora MySQL バージョン 3 へのアップグレード](AuroraMySQL.mysql80-upgrade-procedure.md)
## MySQL 8.0 コミュニティエディションからの機能
Aurora MySQL バージョン 3 の初期リリースは、MySQL 8.0.23 コミュニティエディションと互換性があります。MySQL 8.0 では、以下を含むいくつかの新機能が導入されています。
+ アトミックデータ定義言語 (DDL) のサポート。詳細については、「[アトミックデータ定義言語 (DDL) のサポート](AuroraMySQL.Compare-v2-v3.md#AuroraMySQL.Compare-v2-v3-atomic-ddl)」を参照してください。
+ JSON 関数。使用に関する情報については、*MySQL リファレンスマニュアル* の[JSON 関数](https://dev.mysql.com/doc/refman/8.0/en/json-functions.html)を参照してください。
+ ウィンドウ関数。使用に関する情報については、*MySQL リファレンスマニュアル* の[Window 関数](https://dev.mysql.com/doc/refman/8.0/en/window-functions.html)を参照してください。
+ `WITH` 句を使用した共通テーブル表現 (CTE)。使用に関する情報については、*MySQL リファレンスマニュアル*の [WITH (共通テーブル表現)](https://dev.mysql.com/doc/refman/8.0/en/with.html)を参照してください。
+ `ALTER TABLE` ステートメントの、最適化された `ADD COLUMN` と `RENAME COLUMN` 句 。これらの最適化は「インスタント DDL」と呼ばれます。Aurora MySQL バージョン 3 はコミュニティ MySQL インスタント DDL 特徴と互換性があります。旧 Aurora 高速 DDL特徴は使用されていません。インスタント DDL の使用情報については、[インスタント DDL (Aurora MySQL バージョン 3)](AuroraMySQL.Managing.FastDDL.md#AuroraMySQL.mysql80-instant-ddl) を参照してください。
+ 降順、機能、不可視インデックス。使用に関する情報については、*MySQL リファレンスマニュアル*の[非表示インデックス](https://dev.mysql.com/doc/refman/8.0/en/invisible-indexes.html)、[降順インデックス](https://dev.mysql.com/doc/refman/8.0/en/descending-indexes.html)、および[CREATE INDEX インデックス](https://dev.mysql.com/doc/refman/8.0/en/create-index.html#create-index-functional-key-parts)を参照してください。
+ SQL 文で制御されるロールベースの権限。権限モデルの変更については、[ロールベースの特権モデル](AuroraMySQL.Compare-80-v3.md#AuroraMySQL.privilege-model) を参照してください。
+ `SELECT ... FOR SHARE` 文の`NOWAIT` と `SKIP LOCKED` 句。これらの句は、他のトランザクションが行ロックを解放するのを待つことを避けます。使用の詳細については、*MySQL リファレンスマニュアル*の[読み取りロック](https://dev.mysql.com/doc/refman/8.0/en/innodb-locking-reads.html)を参照してください。
+ バイナリログ (binlog) のレプリケーションの改善。Aurora MySQL の詳細については、[バイナリログレプリケーション](AuroraMySQL.Compare-v2-v3.md#AuroraMySQL.mysql80-binlog) を参照してください。特に、フィルタリングされたレプリケーションを実行できます。使用方法については、*MySQL リファレンスマニュアル*の[サーバがレプリケーションフィルタ規則を評価する方法](https://dev.mysql.com/doc/refman/8.0/en/replication-rules.html)を参照してください。
+ ヒント。MySQL 8.0 互換ヒントのいくつかは、既に Aurora MySQL バージョン 2 にバックポートされています。Aurora MySQL でのヒントの使用については、[Aurora MySQL のヒント](AuroraMySQL.Reference.Hints.md) を参照してください。コミュニティ MySQL 8.0 でのヒントの詳細なリストは、*MySQL リファレンスマニュアル*の[オプティマイザーヒント](https://dev.mysql.com/doc/refman/8.0/en/optimizer-hints.html)を参照してください。
MySQL 8.0 コミュニティエディションに追加された機能の完全なリストについては、ブログ記事 [MySQL 8.0 の新機能の完全なリスト](https://dev.mysql.com/blog-archive/the-complete-list-of-new-features-in-mysql-8-0/) を参照してください。
Aurora MySQL バージョン 3 には、コミュニティ MySQL 8.0.26 からバックポートされた、包括的言語キーワードの変更も含まれています。これらの変更の詳細については、[Aurora MySQL バージョン 3 に対する包括的な言語変更](AuroraMySQL.Compare-v2-v3.md#AuroraMySQL.8.0-inclusive-language) を参照してください。
## 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 のデータベースエンジンの更新](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraMySQLReleaseNotes/AuroraMySQL.Updates.30Updates.html)」を参照してください。
## 新しいパラレルクエリの最適化
Aurora パラレルクエリの最適化は、より多くの SQL 操作に適用されるようになりました。
+ パラレルクエリは、`TEXT`、`BLOB`、`JSON`、`GEOMETRY`、`VARCHAR`、そして 768 バイトより長い `CHAR` のデータ型を含んだテーブルに適用されるようになりました。
+ パラレルクエリは、パーティショニングテーブルを含むクエリを最適化できます。
+ パラレルクエリは、選択リストと `HAVING` 句内でする集計関数の呼び出を伴うクエリを最適化できます。
強化の詳細については、[Aurora MySQL バージョン 3 への パラレルクエリクラスターのアップグレード](aurora-mysql-parallel-query-optimizing.md#aurora-mysql-parallel-query-upgrade-pqv2) を参照してください。Aurora パラレルクエリの一般情報については、[Amazon Aurora MySQL の並列クエリ](aurora-mysql-parallel-query.md) を参照してください。
## データベースの再起動時間を短縮するための最適化
Aurora MySQL DB クラスターは、計画的な停止時と計画外の停止時の両方で高い可用性を備えている必要があります。
データベース管理者は時折データベースのメンテナンスを行う必要があります。このメンテナンスには、データベースのパッチ適用、アップグレード、手動での再起動が必要なデータベースパラメータの変更、インスタンスクラスの変更にかかる時間を短縮するためのフェイルオーバーの実行などが含まれます。これらの計画的なアクションには、ダウンタイムが伴います。
ただし、基盤となるハードウェア障害やデータベースリソースのスロットリングによる予期しないフェイルオーバーなど、計画外のアクションによってもダウンタイムが発生することもあります。これらの計画的なアクションでも、計画外のアクションでも、必ずデータベースの再起動が必要です。
Aurora MySQL バージョン 3.05 以降では、データベースの再起動時間を短縮するための最適化が導入されました。これらの最適化により、最適化を行わない場合と比べてダウンタイムが最大 65% 短縮され、再起動後のデータベースワークロードの中断も少なくなります。
データベースのスタートアップ時には、多くの内部メモリコンポーネントが初期化されます。これらの中で最大のものは [InnoDB バッファープール](https://aws.amazon.com/blogs/database/best-practices-for-amazon-aurora-mysql-database-configuration/)で、Aurora MySQL ではデフォルトでインスタンスのメモリサイズの 75% です。テストの結果、初期化時間は InnoDB バッファプールのサイズに比例し、DB インスタンスクラスのサイズに合わせて調整されることがわかりました。この初期化フェーズでは、データベースは接続を受け付けられないため、再起動時のダウンタイムが長くなります。Aurora MySQL 高速再起動の第 1 フェーズでは、バッファープールの初期化が最適化されます。これにより、データベースの初期化時間が短縮され、全体的な再起動時間が短縮されます。
詳細については、ブログ「[Amazon Aurora MySQL データベースの再起動時間の最適化によってダウンタイムを削減する](https://aws.amazon.com/blogs/database/reduce-downtime-with-amazon-aurora-mysql-database-restart-time-optimizations/)」を参照してください。
# Aurora MySQL バージョン 3 での新しい一時テーブルの動作
Aurora MySQL バージョン 3 では、一時テーブルの処理方法は、以前の Aurora MySQL バージョンとは異なります。この新しい動作は MySQL 8.0 コミュニティエディションから継承されています。Aurora MySQL バージョン 3 で作成できる一時テーブルには、次の 2 つのタイプがあります。
+ 内部 (または*黙示的*) 一時テーブル — 集計の並べ替え、派生テーブル、共通テーブル式 (CTE) などの操作を処理するために Aurora MySQL エンジンによって作成されます。
+ ユーザー作成 (または*明示的*) 一時テーブル — Aurora MySQL エンジンが`CREATE TEMPORARY TABLE`表示されます。
Aurora Reader DB インスタンスの内部およびユーザー作成一時テーブルの両方について、その他の考慮事項があります。これらについては、以降のセクションで説明します。
**Topics**
+ [内部 (黙示的) 一時テーブルのストレージエンジン](#ams3-temptable-behavior-engine)
+ [内部メモリ内一時テーブルのサイズを制限する](#ams3-temptable-behavior-limit)
+ [Aurora レプリカの内部一時テーブルのフルネス問題の緩和](#ams3-temptable-behavior-mitigate)
+ [Aurora MySQL DB インスタンスでの temptable\$1max\$1mmap パラメータの最適化](#ams-optimize-temptable_max_mmap)
+ [リーダー DB インスタンスでユーザーが作成した (明示的な) 一時テーブル](#ams3-temptable-behavior.user)
+ [一時テーブル作成エラーと軽減](#ams3-temptable-behavior.errors)
## 内部 (黙示的) 一時テーブルのストレージエンジン
中間結果セットを生成するとき、Aurora MySQL は最初にメモリ内一時テーブルへの書き込みを試みます。データ型に互換性がないか、制限が設定されていることが原因で、これがうまくいかない可能性があります。その場合、一時テーブルはメモリに保持されるのではなく、ディスク上の一時テーブルに変換されます。これについての詳細は、MySQL ドキュメントの「[MySQL での内部一時テーブルの使用](https://dev.mysql.com/doc/refman/8.0/en/internal-temporary-tables.html)」を参照してください。
Aurora MySQL バージョン 3 では、内部一時テーブルの動作方法は、以前の Aurora MySQL バージョンとは異なります。このような一時テーブルの InnoDB ストレージエンジンと MyISAM ストレージエンジンのいずれかを選択する代わりに、現在は `TempTable` ストレージエンジンと `MEMORY` ストレージエンジンのいずれかを選択します。
`TempTable` ストレージエンジンを使用すると、特定のデータの処理方法について追加の選択を行うことができます。影響を受けるデータは、DB インスタンスのすべての内部一時テーブルを保持するメモリプールをオーバーフローします。
これらの選択は、大量の一時データを生成するクエリのパフォーマンスに影響します。例えば、ラージ テーブルの `GROUP BY` のような集約を実行している場合などです。
**ヒント**
ワークロードに内部一時テーブルを生成するクエリが含まれている場合は、ベンチマークを実行し、パフォーマンス関連のメトリックをモニタリングして、この変更によるアプリケーションの動作を確認します。
場合によっては、一時データ量は `TempTable` メモリプールに収まるか、または少量だけメモリプールから溢れます。このような場合は、内部一時テーブルおよびメモリマップファイルの `TempTable` 設定を使用して、オーバーフローデータを保持することをお勧めします。この設定はデフォルトです。
`TempTable` ストレージエンジンがデフォルトです。`TempTable` は、テーブルあたりの最大メモリ制限ではなく、このエンジンを使うすべての一時テーブルの共通メモリプールを使用します。このメモリプールのサイズは、[temptable\$1max\$1ram](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_max_ram) パラメータで特定されます。16 GB 以上のメモリを持つ DB インスタンスでは 1 GB、メモリが 16 GB 未満の DB インスタンスでは 16 MB がデフォルトになります。メモリプールのサイズは、セッションレベルのメモリ消費に影響します。
`TempTable` ストレージエンジンを使用するときに、一時データがメモリプールのサイズを超えることがあります。その場合、Aurora MySQL は二次的なメカニズムを使用してオーバーフローデータを保存します。
[temptable\$1max\$1mmap](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_max_mmap) パラメータを設定して、メモリマップテ一時ファイルまたはディスク上の InnoDB 内部一時テーブルのどちらにデータがオーバーフローするか、指定することができます。これらのオーバーフローメカニズムの異なるデータ形式とオーバーフロー基準は、クエリのパフォーマンスに影響を与える可能性があります。例えば、ディスクに書き込まれるデータ量や、ディスクストレージのスループットに対する要求に影響します。
Aurora MySQL バージョン 3 は、オーバーフローデータを次の方法で保存します。
+ ライター DB インスタンスでは、InnoDB 内部の一時テーブルまたはメモリマップド一時ファイルにオーバーフローするデータは、インスタンスのローカルストレージに存在します。
+ リーダー DB インスタンスでは、オーバーフローデータは常にローカルストレージ上のメモリマップド一時ファイルに存在します。
読み取り専用インスタンスでは Aurora クラスターボリュームにデータを保存できません。
内部一時テーブルに関連する設定パラメータは、クラスター内のライターインスタンスとリーダーインスタンスに対して異なる方法で適用されます。
+ リーダーインスタンスの場合、Aurora MySQL は常に `TempTable` ストレージエンジンを使用します。
+ `temptable_max_mmap` のデフォルトサイズは、DB インスタンスのメモリサイズに関係なく、ライターインスタンスとリーダーインスタンスの両方で 1 GB です。この値はライターインスタンスとリーダーインスタンスの両方で調整できます。
+ `temptable_max_mmap` を `0` に設定すると、ライターインスタンスでのメモリマップされた一時ファイルの使用がオフになります。
+ リーダーインスタンスでは、`temptable_max_mmap` を `0` に設定することはできません。
**注記**
[temptable\$1use\$1mmap](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_use_mmap) パラメーターの使用はお勧めしません。これは非推奨であり、将来の MySQL リリースでサポートが削除される予定です。
## 内部メモリ内一時テーブルのサイズを制限する
[内部 (黙示的) 一時テーブルのストレージエンジン](#ams3-temptable-behavior-engine) で説明したように、[temptable\$1max\$1ram](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_max_ram) および [temptable\$1max\$1mmap](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_max_mmap) 設定を使用して、一時テーブルリソースをグローバルに制御できます。
また、[tmp\$1table\$1size](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_tmp_table_size) DB パラメータを使用して、個々の内部メモリ内一時テーブルのサイズを制限することもできます。この制限は、個々のクエリがグローバル一時テーブルリソースを大量に消費し、これらのリソースを必要とする同時クエリのパフォーマンスに影響を与えるのを防ぐことを目的としています。
`tmp_table_size` パラメータは、Aurora MySQL バージョン 3 の `MEMORY` ストレージエンジンによって作成される一時テーブルの最大サイズを定義します。
Aurora MySQL バージョン 3.04 以降では、`tmp_table_size` は、`aurora_tmptable_enable_per_table_limit` DB パラメータが `ON` に設定されているときに `TempTable` ストレージエンジンによって作成される一時テーブルの最大サイズも定義します。この動作はデフォルトでは無効になっています (`OFF`)、これは Aurora MySQL バージョン 3.03 以前のバージョンと同じ動作です。
+ `aurora_tmptable_enable_per_table_limit` が `OFF` のとき、`tmp_table_size` は、`TempTable` ストレージエンジンによって作成される内部メモリ内一時テーブルでは考慮されません。
ただし、その場合でも、グローバル `TempTable` リソース制限は適用されます。Aurora MySQL は、グローバル `TempTable` リソース制限に達すると、次のように動作します。
+ ライター DB インスタンス — Aurora MySQL は、メモリ内一時テーブルを InnoDB オンディスク一時テーブルに自動的に変換します。
+ リーダー DB インスタンス — クエリはエラーで終了します。
```
ERROR 1114 (HY000): The table '/rdsdbdata/tmp/#sqlxx_xxx' is full
```
+ `aurora_tmptable_enable_per_table_limit` が `ON` のとき、Aurora MySQL は、`tmp_table_size` 制限に達すると、次のように動作します。
+ ライター DB インスタンス — Aurora MySQL は、メモリ内一時テーブルを InnoDB オンディスク一時テーブルに自動的に変換します。
+ リーダー DB インスタンス — クエリはエラーで終了します。
```
ERROR 1114 (HY000): The table '/rdsdbdata/tmp/#sqlxx_xxx' is full
```
この場合、グローバル `TempTable` リソース制限とテーブルごとの制限の両方が適用されます。
**注記**
`aurora_tmptable_enable_per_table_limit` パラメータは、[ internal\$1tmp\$1mem\$1storage\$1engine](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_internal_tmp_mem_storage_engine) が `MEMORY` に設定されたときには、効果がありません。この場合、メモリ内一時テーブルの最大サイズは、[tmp\$1table\$1size](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_tmp_table_size) または [max\$1heap\$1table\$1size](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_max_heap_table_size) のいずれか小さい方の値によって定義されます。
以下の例は、ライター DB インスタンスとリーダー DB インスタンスについて、`aurora_tmptable_enable_per_table_limit` パラメータの動作を示しています。
**Example `aurora_tmptable_enable_per_table_limit` が `OFF` に設定されたライター DB インスタンス**
メモリ内一時テーブルは InnoDB オンディスク一時テーブルに変換されません。
```
mysql> set aurora_tmptable_enable_per_table_limit=0;
Query OK, 0 rows affected (0.00 sec)
mysql> select @@innodb_read_only,@@aurora_version,@@aurora_tmptable_enable_per_table_limit,@@temptable_max_ram,@@temptable_max_mmap;
+--------------------+------------------+------------------------------------------+---------------------+----------------------+
| @@innodb_read_only | @@aurora_version | @@aurora_tmptable_enable_per_table_limit | @@temptable_max_ram | @@temptable_max_mmap |
+--------------------+------------------+------------------------------------------+---------------------+----------------------+
| 0 | 3.04.0 | 0 | 1073741824 | 1073741824 |
+--------------------+------------------+------------------------------------------+---------------------+----------------------+
1 row in set (0.00 sec)
mysql> show status like '%created_tmp_disk%';
+-------------------------+-------+
| Variable_name | Value |
+-------------------------+-------+
| Created_tmp_disk_tables | 0 |
+-------------------------+-------+
1 row in set (0.00 sec)
mysql> set cte_max_recursion_depth=4294967295;
Query OK, 0 rows affected (0.00 sec)
mysql> WITH RECURSIVE cte (n) AS (SELECT 1 UNION ALL SELECT n + 1 FROM cte WHERE n < 60000000) SELECT max(n) FROM cte;
+----------+
| max(n) |
+----------+
| 60000000 |
+----------+
1 row in set (13.99 sec)
mysql> show status like '%created_tmp_disk%';
+-------------------------+-------+
| Variable_name | Value |
+-------------------------+-------+
| Created_tmp_disk_tables | 0 |
+-------------------------+-------+
1 row in set (0.00 sec)
```
**Example `aurora_tmptable_enable_per_table_limit` が `ON` に設定されたライター DB インスタンス**
メモリ内一時テーブルは InnoDB オンディスク一時テーブルに変換されます。
```
mysql> set aurora_tmptable_enable_per_table_limit=1;
Query OK, 0 rows affected (0.00 sec)
mysql> select @@innodb_read_only,@@aurora_version,@@aurora_tmptable_enable_per_table_limit,@@tmp_table_size;
+--------------------+------------------+------------------------------------------+------------------+
| @@innodb_read_only | @@aurora_version | @@aurora_tmptable_enable_per_table_limit | @@tmp_table_size |
+--------------------+------------------+------------------------------------------+------------------+
| 0 | 3.04.0 | 1 | 16777216 |
+--------------------+------------------+------------------------------------------+------------------+
1 row in set (0.00 sec)
mysql> set cte_max_recursion_depth=4294967295;
Query OK, 0 rows affected (0.00 sec)
mysql> show status like '%created_tmp_disk%';
+-------------------------+-------+
| Variable_name | Value |
+-------------------------+-------+
| Created_tmp_disk_tables | 0 |
+-------------------------+-------+
1 row in set (0.00 sec)
mysql> WITH RECURSIVE cte (n) AS (SELECT 1 UNION ALL SELECT n + 1 FROM cte WHERE n < 6000000) SELECT max(n) FROM cte;
+---------+
| max(n) |
+---------+
| 6000000 |
+---------+
1 row in set (4.10 sec)
mysql> show status like '%created_tmp_disk%';
+-------------------------+-------+
| Variable_name | Value |
+-------------------------+-------+
| Created_tmp_disk_tables | 1 |
+-------------------------+-------+
1 row in set (0.00 sec)
```
**Example `aurora_tmptable_enable_per_table_limit` が `OFF` に設定されたリーダー DB インスタンス**
`tmp_table_size` は適用されず、グローバル `TempTable` リソースの上限に達していないため、クエリはエラーなしで終了します。
```
mysql> set aurora_tmptable_enable_per_table_limit=0;
Query OK, 0 rows affected (0.00 sec)
mysql> select @@innodb_read_only,@@aurora_version,@@aurora_tmptable_enable_per_table_limit,@@temptable_max_ram,@@temptable_max_mmap;
+--------------------+------------------+------------------------------------------+---------------------+----------------------+
| @@innodb_read_only | @@aurora_version | @@aurora_tmptable_enable_per_table_limit | @@temptable_max_ram | @@temptable_max_mmap |
+--------------------+------------------+------------------------------------------+---------------------+----------------------+
| 1 | 3.04.0 | 0 | 1073741824 | 1073741824 |
+--------------------+------------------+------------------------------------------+---------------------+----------------------+
1 row in set (0.00 sec)
mysql> set cte_max_recursion_depth=4294967295;
Query OK, 0 rows affected (0.00 sec)
mysql> WITH RECURSIVE cte (n) AS (SELECT 1 UNION ALL SELECT n + 1 FROM cte WHERE n < 60000000) SELECT max(n) FROM cte;
+----------+
| max(n) |
+----------+
| 60000000 |
+----------+
1 row in set (14.05 sec)
```
**Example `aurora_tmptable_enable_per_table_limit` が `OFF` に設定されたリーダー DB インスタンス**
`aurora_tmptable_enable_per_table_limit` が OFF に設定されている場合、このクエリはグローバル TempTable リソース制限に達します。クエリはリーダーインスタンスのエラーで終了します。
```
mysql> set aurora_tmptable_enable_per_table_limit=0;
Query OK, 0 rows affected (0.00 sec)
mysql> select @@innodb_read_only,@@aurora_version,@@aurora_tmptable_enable_per_table_limit,@@temptable_max_ram,@@temptable_max_mmap;
+--------------------+------------------+------------------------------------------+---------------------+----------------------+
| @@innodb_read_only | @@aurora_version | @@aurora_tmptable_enable_per_table_limit | @@temptable_max_ram | @@temptable_max_mmap |
+--------------------+------------------+------------------------------------------+---------------------+----------------------+
| 1 | 3.04.0 | 0 | 1073741824 | 1073741824 |
+--------------------+------------------+------------------------------------------+---------------------+----------------------+
1 row in set (0.00 sec)
mysql> set cte_max_recursion_depth=4294967295;
Query OK, 0 rows affected (0.01 sec)
mysql> WITH RECURSIVE cte (n) AS (SELECT 1 UNION ALL SELECT n + 1 FROM cte WHERE n < 120000000) SELECT max(n) FROM cte;
ERROR 1114 (HY000): The table '/rdsdbdata/tmp/#sqlfd_1586_2' is full
```
**Example `aurora_tmptable_enable_per_table_limit` が `ON` に設定されたリーダー DB インスタンス**
`tmp_table_size` 制限に達すると、クエリはエラーで終了します。
```
mysql> set aurora_tmptable_enable_per_table_limit=1;
Query OK, 0 rows affected (0.00 sec)
mysql> select @@innodb_read_only,@@aurora_version,@@aurora_tmptable_enable_per_table_limit,@@tmp_table_size;
+--------------------+------------------+------------------------------------------+------------------+
| @@innodb_read_only | @@aurora_version | @@aurora_tmptable_enable_per_table_limit | @@tmp_table_size |
+--------------------+------------------+------------------------------------------+------------------+
| 1 | 3.04.0 | 1 | 16777216 |
+--------------------+------------------+------------------------------------------+------------------+
1 row in set (0.00 sec)
mysql> set cte_max_recursion_depth=4294967295;
Query OK, 0 rows affected (0.00 sec)
mysql> WITH RECURSIVE cte (n) AS (SELECT 1 UNION ALL SELECT n + 1 FROM cte WHERE n < 6000000) SELECT max(n) FROM cte;
ERROR 1114 (HY000): The table '/rdsdbdata/tmp/#sqlfd_8_2' is full
```
## Aurora レプリカの内部一時テーブルのフルネス問題の緩和
一時テーブルのサイズ制限の問題を回避するには、`temptable_max_ram` と `temptable_max_mmap`パラメータを、ワークロードの要件に適合する値を組み合わせて指定します。
`temptable_max_ram` パラメータの値を設定するときは注意してください。この値の設定が高すぎると、データベースインスタンスの使用可能なメモリが減少し、メモリ不足状態が発生する可能性があります。DB インスタンスの平均空きメモリ量を監視します。インスタンスには十分な量の空きメモリが残るように `temptable_max_ram` の適切な値を決定します。詳細については、「[Amazon Aurora の解放可能なメモリの問題](CHAP_Troubleshooting.md#Troubleshooting.FreeableMemory)」を参照してください。
また、ローカルストレージのサイズと一時テーブル領域の消費量をモニタリングすることも重要です。特定の DB インスタンスで使用できる一時ストレージをモニタリングするには、`FreeLocalStorage` Amazon CloudWatch メトリクスを使用できます。詳細については、「[Amazon Aurora の Amazon CloudWatch メトリクス](Aurora.AuroraMonitoring.Metrics.md)」を参照してください。
**注記**
この手順は、`aurora_tmptable_enable_per_table_limit` パラメータが `ON` に設定されているときには機能しません。詳細については、「[内部メモリ内一時テーブルのサイズを制限する](#ams3-temptable-behavior-limit)」を参照してください。
**Example 1**
一時テーブルの累積サイズが 20 GiB になることがわかっています。インメモリ一時テーブルを 2 GiB に設定し、ディスク上で最大 20 GiB に拡張します。
`temptable_max_ram` を **2,147,483,648** に、`temptable_max_mmap` を **21,474,836,480** に設定します。これらの値はバイト単位です。
これらのパラメータ設定により、一時テーブルが累積合計 22 GiB に拡張できます。
**Example 2**
現在のインスタンスサイズは 16xlarge 以上です。必要な一時テーブルの合計サイズが不明です。最大 4 GiB のメモリと、ディスク上の使用可能な最大ストレージサイズまで使用できるようにしたいと思っています。
`temptable_max_ram` を **4,294,967,296** に、`temptable_max_mmap` を **1,099,511,627,776** に設定します。これらの値はバイト単位です。
`temptable_max_mmap` を 1 TiB に設定します。これは、16 倍の大きな Aurora DB インスタンスの最大ローカルストレージである 1.2 TiB 未満です。
小さいインスタンスサイズで、使用可能なローカルストレージがいっぱいにならないように `temptable_max_mmap` の値を調整します。例えば、2xlarge インスタンスで使用できるローカルストレージは 160 GiB のみです。したがって、値を 160 GiB 未満に設定することをお勧めします。DB インスタンスサイズで使用可能なローカルストレージの詳細については、「[Aurora MySQL 用の一時ストレージの制限一時ストレージの制限](AuroraMySQL.Managing.Performance.md#AuroraMySQL.Managing.TempStorage)」を参照してください。
## Aurora MySQL DB インスタンスでの temptable\$1max\$1mmap パラメータの最適化
Aurora MySQL の `temptable_max_mmap` パラメータは、ディスク上の InnoDB 一時テーブルにオーバーフローする (ライター DB インスタンス) 前、またはエラーを発生させる (リーダー DB インスタンス) 前に、メモリマップファイルで利用可能なローカルディスク領域の最大量を制御します。この DB インスタンスパラメータを適切に設定すると、DB インスタンスのパフォーマンスを最適化するのに役立ちます。
**前提条件**
1. パフォーマンススキーマが有効になっていることを確認します。次の SQL コマンドを実行して、これを検証できます。
```
SELECT @@performance_schema;
```
出力値 `1` は、有効になっていることを示します。
1. 一時テーブルのメモリ計測が有効になっていることを確認します。次の SQL コマンドを実行して、これを検証できます。
```
SELECT name, enabled FROM performance_schema.setup_instruments WHERE name LIKE '%memory%temptable%';
```
`enabled` 列は、関連する一時テーブルのメモリ計測エントリに対して `YES` を示しています。
**一時テーブルの使用量のモニタリング**
`temptable_max_mmap` の初期値を設定するときは、使用している DB インスタンスクラスのローカルストレージサイズの 80% から開始することをお勧めします。これにより、一時テーブルが効率的に動作するために十分なディスク容量が確保され、インスタンス上の他のディスク使用量のための容量も確保されます。
DB インスタンスクラスのローカルストレージサイズを確認するには、「[Aurora MySQL 用の一時ストレージの制限一時ストレージの制限](AuroraMySQL.Managing.Performance.md#AuroraMySQL.Managing.TempStorage)」を参照してください。
例えば、db.r5.large DB インスタンスクラスを使用している場合、ローカルストレージサイズは 32 GiB です。この場合、最初に `temptable_max_mmap` パラメータを 32 GiB の 80%、つまり 25.6 GiB に設定します。
`temptable_max_mmap` の初期値を設定したら、Aurora MySQL インスタンスでピークワークロードを実行します。次の SQL クエリを使用して、一時テーブルの現在のディスク使用量と高いディスク使用量をモニタリングします。
```
SELECT event_name, current_count, current_alloc, current_avg_alloc, high_count, high_alloc, high_avg_alloc
FROM sys.memory_global_by_current_bytes WHERE event_name LIKE 'memory/temptable/%';
```
このクエリによって以下の情報を取得します。
+ `event_name` – 一時テーブルのメモリまたはディスク使用量イベントの名前。
+ `current_count` – 割り当てられている一時テーブルのメモリまたはディスクブロックの現在の数。
+ `current_alloc` – 一時テーブルに割り当てられているメモリまたはディスクの現在の量。
+ `current_avg_alloc` – 一時テーブルのメモリまたはディスクブロックの現在の平均サイズ。
+ `high_count` – 割り当てられている一時テーブルのメモリまたはディスクブロックの最大数。
+ `high_alloc` – 一時テーブルに割り当てられているメモリまたはディスクの最大量。
+ `high_avg_alloc` – 一時テーブルのメモリまたはディスクブロックの最大平均サイズ。
この設定を使用してクエリが Table is full エラーで失敗する場合、ワークロードが一時テーブルオペレーションにより多くのディスク容量を必要とすることを示します。この場合、DB インスタンスのサイズを、ローカルストレージ容量がより多いインスタンスサイズに増やすことを検討してください。
**最適な `temptable_max_mmap` 値の設定**
`temptable_max_mmap` パラメータをモニタリングして適切なサイズを設定するには、次の手順に従います。
1. 前のクエリの出力を確認し、`high_alloc` 列で示されている、一時テーブルのピークディスク使用量を特定します。
1. 一時テーブルのピークディスク使用量に基づいて、Aurora MySQL DB インスタンスの DB パラメータグループの `temptable_max_mmap` パラメータを調整します。
将来の増加に対応するために、一時テーブルのピークディスク使用量よりもわずかに高い値を設定します。
1. DB インスタンスにパラメータグループの変更を適用します。
1. ピークワークロード中に一時テーブルのディスク使用量を再度モニタリングして、新しい `temptable_max_mmap` 値が適切であることを確認します。
1. 必要に応じて前のステップを繰り返して、`temptable_max_mmap` パラメータを微調整します。
## リーダー DB インスタンスでユーザーが作成した (明示的な) 一時テーブル
`CREATE TABLE` ステートメントの `TEMPORARY` キーワードを使用して、明示的な一時テーブルを作成できます。Aurora DB クラスター内のライター DB インスタンスでは、明示的な一時テーブルがサポートされています。リーダー DB インスタンスで明示的な一時テーブルを使用することもできますが、テーブルでは InnoDB ストレージエンジンの使用を強制することはできません。
Aurora MySQL Reader DB インスタンスで明示的な一時テーブルを作成する際のエラーを回避するには、次の方法のいずれか、または両方で、すべての `CREATE TEMPORARY TABLE` ステートメントを実行してください。
+ `ENGINE=InnoDB` 句を指定しないでください。
+ SQL モードを `NO_ENGINE_SUBSTITUTION` に設定しないでください。
## 一時テーブル作成エラーと軽減
受け取るエラーは、プレーン `CREATE TEMPORARY TABLE` ステートメントまたはバリエーション `CREATE TEMPORARY TABLE AS SELECT` を使うかどうかによって異なります。次の例では、さまざまなタイプのエラーを示しています。
この一時テーブルの動作は、読み取り専用インスタンスにのみ適用されます。この初期の例では、セッションが接続されているインスタンスの種類を確認します。
```
mysql> select @@innodb_read_only;
+--------------------+
| @@innodb_read_only |
+--------------------+
| 1 |
+--------------------+
```
プレーン `CREATE TEMPORARY TABLE` ステートメントの場合、`NO_ENGINE_SUBSTITUTION` SQL モードが有効になっているとステートメントは失敗します。メトリクス `NO_ENGINE_SUBSTITUTION` がオフ (デフォルト) の場合、適切なエンジン置換が行われ、一時テーブルの作成は成功します。
```
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 モードが有効になっていると、ステートメントは失敗します。メトリクス `NO_ENGINE_SUBSTITUTION` がオフ (デフォルト) の場合、適切なエンジン置換が行われ、一時テーブルの作成は成功します。
```
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> show create table tt3;
+-------+----------------------------------------------------------+
| Table | Create Table |
+-------+----------------------------------------------------------+
| tt3 | CREATE TEMPORARY TABLE `tt3` (
`id` int DEFAULT NULL
) ENGINE=MyISAM DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci |
+-------+----------------------------------------------------------+
1 row in set (0.00 sec)
```
Aurora MySQL バージョン 3 での一時テーブルのストレージ側面とパフォーマンスへの影響の詳細については、ブログ記事「[Amazon RDS for MySQL および Amazon Aurora MySQL の TempTable ストレージエンジンを使用する](https://aws.amazon.com/blogs/database/use-the-temptable-storage-engine-on-amazon-rds-for-mysql-and-amazon-aurora-mysql/)」を参照してください。
# Aurora MySQL バージョン 2 と Aurora MySQL バージョン 3 の比較
Aurora MySQL バージョン 2 クラスターをバージョン 3 にアップグレードする際に注意すべき変更については、以下を参照してください。
**Topics**
+ [アトミックデータ定義言語 (DDL) のサポート](#AuroraMySQL.Compare-v2-v3-atomic-ddl)
+ [Aurora MySQL バージョン 2 と 3 の特徴の違い](#AuroraMySQL.Compare-v2-v3-features)
+ [インスタンスクラスのサポート](#AuroraMySQL.mysql80-instance-classes)
+ [Aurora MySQL バージョン 3 のパラメータ変更](#AuroraMySQL.mysql80-parameter-changes)
+ [ステータス可変](#AuroraMySQL.mysql80-status-vars)
+ [Aurora MySQL バージョン 3 に対する包括的な言語変更](#AuroraMySQL.8.0-inclusive-language)
+ [AUTO\$1INCREMENT 値](#AuroraMySQL.mysql80-autoincrement)
+ [バイナリログレプリケーション](#AuroraMySQL.mysql80-binlog)
## アトミックデータ定義言語 (DDL) のサポート
MySQL 5.7 から 8.0 への最大の変更の 1 つは、[アトミックデータディクショナリ](https://dev.mysql.com/doc/refman/8.0/en/data-dictionary-file-removal.html)の導入です。MySQL 8.0 より前では、MySQL データディクショナリはファイルベースのアプローチを使用して、テーブル定義 (.frm)、トリガー (.trg)、関数などのメタデータをストレージエンジンのメタデータ (InnoDB など) とは別に保存していました。これには、DDL オペレーション中に予期しない事態が発生した場合にテーブルが "[孤立](https://dev.mysql.com/doc/refman/5.7/en/innodb-troubleshooting-datadict.html)" し、ファイルベースとストレージエンジンのメタデータが同期しなくなるリスクなど、いくつかの問題がありました。
これを修正するために、MySQL 8.0 は、`mysql` スキーマ内の内部 InnoDB テーブルのセットにすべてのメタデータを保存するアトミックデータディクショナリを導入しました。この新しいアーキテクチャは、古いファイルベースのアプローチから "アトミック DDL" 問題を解決し、データベースメタデータを管理するトランザクションの [ACID](https://en.wikipedia.org/wiki/ACID) 準拠の方法を提供します。アトミックデータディクショナリの詳細については、「MySQL リファレンスマニュアル」の「[Removal of file-based metadata storage](https://dev.mysql.com/doc/refman/8.0/en/data-dictionary-file-removal.html)」と「[Atomic data definition statement support](https://dev.mysql.com/doc/refman/8.0/en/atomic-ddl.html)」を参照してください。**
このアーキテクチャの変更により、Aurora MySQL バージョン 2 からバージョン 3 にアップグレードする際には、次の点を考慮する必要があります。
+ バージョン 2 からのファイルベースのメタデータは、バージョン 3 へのアップグレードプロセス中に新しいデータディクショナリテーブルに移行する必要があります。移行されるデータベースオブジェクトの数によっては、時間がかかる場合があります。
+ また、この変更により、MySQL 5.7 から 8.0 にアップグレードする前に対処する必要がある可能性のある新しい非互換性が導入されました。例えば、8.0 には、既存のデータベースオブジェクト名と競合する可能性のある新しい予約キーワードがいくつかあります。
エンジンをアップグレードする前にこれらの非互換性を特定するため、Aurora MySQL は一連のアップグレード互換性チェック (事前チェック) を実行して、データディクショナリのアップグレードを実行する前に、データベースディクショナリに互換性のないオブジェクトがあるかどうかを判断します。事前チェックの詳細については、「[Aurora MySQL のメジャーバージョンアップグレードの事前チェック](AuroraMySQL.upgrade-prechecks.md)」を参照してください。
## Aurora MySQL バージョン 2 と 3 の特徴の違い
次の Amazon Aurora MySQL 機能は Aurora MySQL 5.7 でサポートされていますが、これらの機能は現在 MySQL 8.0 の Aurora MySQL ではサポートされていません。
+ Aurora Serverless v1 クラスターに Aurora MySQL バージョン 3 を使用することはできません。Aurora MySQL バージョン 3 は Aurora Serverless v2 で動作します。
+ ラボモードは Aurora MySQL バージョン 3 には適用されません。Aurora MySQL バージョン 3 には、ラボモードの機能はありません。インスタント DDL は、過去にラボモードで使用可能だった高速オンライン DDL特徴よりも優先されます。例については、「[インスタント DDL (Aurora MySQL バージョン 3)](AuroraMySQL.Managing.FastDDL.md#AuroraMySQL.mysql80-instant-ddl)」を参照してください。
+ クエリキャッシュはコミュニティ MySQL 8.0 から削除され、Aurora MySQL バージョン 3 からも削除されます。
+ Aurora MySQL バージョン 3 はコミュニティ MySQL ハッシュ統合特徴と互換性があります。ハッシュ結合の Aurora 固有の実装は Aurora MySQL バージョン 2 では使用されていません。ハッシュ結合を Aurora パラレルクエリで使用する方法については、[パラレルクエリクラスターのハッシュ結合の有効化](aurora-mysql-parallel-query-enabling.md#aurora-mysql-parallel-query-enabling-hash-join) および [Aurora MySQL のヒント](AuroraMySQL.Reference.Hints.md) を参照してください。ハッシュ結合の一般的な使用方法については、*MySQL リファレンスマニュアル*の[ハッシュ結合の最適化](https://dev.mysql.com/doc/refman/8.0/en/hash-joins.html)を参照してください。
+ Aurora MySQL バージョン 2 で非推奨であったた `mysql.lambda_async` ストアドプロシージャは、バージョン 3 で削除されます。バージョン 3 では、非同期関数 `lambda_async` を代わりに使用します。
+ Aurora MySQL バージョン 3 のデフォルト文字セットは `utf8mb4` です。Aurora MySQL バージョン 2 のデフォルト文字セットは `latin1` です。この文字セットの詳細については、*MySQL リファレンスマニュアル*の[utf8mb4 文字セット (4 バイトの UTF-8 Unicode エンコード)](https://dev.mysql.com/doc/refman/8.0/en/charset-unicode-utf8mb4.html)を参照してください。
Aurora MySQL の一部の機能は、AWS リージョンと DB エンジンのバージョンの特定の組み合わせで利用可能です。詳細については、「[AWS リージョン と Aurora DB エンジンにより Amazon Aurora でサポートされている機能](Concepts.AuroraFeaturesRegionsDBEngines.grids.md)」を参照してください。
## インスタンスクラスのサポート
Aurora MySQL バージョン 3 では、Aurora MySQL バージョン 2 とは異なるインスタンスクラスのセットがサポートされています。
+ 大規模なインスタンスの場合は、`db.r5` や `db.r6g`、`db.x2g` のような最新のインスタンスクラスを使用できます。
+ 小規模なインスタンスの場合は、`db.t3` や `db.t4g` のような最新のインスタンスクラスを使用できます。
**注記**
T DB インスタンスクラスは、開発サーバーおよびテストサーバー、またはその他の本稼働以外のサーバーにのみ使用することをお勧めします。T インスタンスクラスの詳細については、「[開発やテストのための T インスタンスクラスの使用](AuroraMySQL.BestPractices.Performance.md#AuroraMySQL.BestPractices.T2Medium)」を参照してください。
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 インスタンスクラスの詳細については、[Amazon Aurora DB インスタンスクラス](Concepts.DBInstanceClass.md) を参照してください。
## 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 グローバルデータベースでは、`lower_case_table_names` パラメータがオンの場合、Aurora MySQL バージョン 2 からバージョン 3 へのインプレースアップグレードを実行できません。代わりに、スナップショット復元方法を使用してください。
Aurora MySQL バージョン 3 では、`init_connect` および `read_only` パラメータは `CONNECTION_ADMIN` 権限を持つユーザーには適用されません。これには Aurora マスターユーザーが含まれます。詳細については、「[ロールベースの特権モデル](AuroraMySQL.Compare-80-v3.md#AuroraMySQL.privilege-model)」を参照してください。
すべての Aurora MySQL クラスターパラメータのリストについては、「[クラスターレベルのパラメータ](AuroraMySQL.Reference.ParameterGroups.md#AuroraMySQL.Reference.Parameters.Cluster)」を参照してください。この表では、Aurora MySQL バージョン 2 および 3 のすべてのパラメータについて説明します。この表には、Aurora MySQL バージョン 3 で新しく追加されたパラメータや Aurora MySQL バージョン 3 から削除されたパラメータを示す注記が含まれています。
すべての Aurora MySQL インスタンスパラメータのリストについては、「[インスタンスレベルのパラメータ](AuroraMySQL.Reference.ParameterGroups.md#AuroraMySQL.Reference.Parameters.Instance)」を参照してください。この表では、Aurora MySQL バージョン 2 および 3 のすべてのパラメータについて説明します。この表には、Aurora MySQL バージョン 3 で新しく追加されたパラメータがどれか、また Aurora MySQL バージョン 3 から削除されたパラメータはどれかを示した注記が含まれています。また、Aurora MySQL バージョン 3 ではなく、以前のバージョンで変更可能なパラメータを示す注記も含まれています。
変更されたパラメータ名の詳細については、[Aurora MySQL バージョン 3 に対する包括的な言語変更](#AuroraMySQL.8.0-inclusive-language) を参照してください。
## ステータス可変
Aurora MySQL に適用できないステータス可変の詳細については、[Aurora MySQL に適応されない MySQL ステータス可変](AuroraMySQL.Reference.GlobalStatusVars.md#AuroraMySQL.Reference.StatusVars.Inapplicable) を参照してください。
## 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\$1fwd\$1master\$1dml\$1stmt\$1duration | Aurora\$1fwd\$1writer\$1dml\$1stmt\$1duration |
| Aurora\$1fwd\$1master\$1dml\$1stmt\$1count | Aurora\$1fwd\$1writer\$1dml\$1stmt\$1count |
| Aurora\$1fwd\$1master\$1select\$1stmt\$1duration | Aurora\$1fwd\$1writer\$1select\$1stmt\$1duration |
| Aurora\$1fwd\$1master\$1select\$1stmt\$1count | Aurora\$1fwd\$1writer\$1select\$1stmt\$1count |
| Aurora\$1fwd\$1master\$1errors\$1session\$1timeout | Aurora\$1fwd\$1writer\$1errors\$1session\$1timeout |
| Aurora\$1fwd\$1master\$1open\$1sessions | Aurora\$1fwd\$1writer\$1open\$1sessions |
| Aurora\$1fwd\$1master\$1errors\$1session\$1limit | Aurora\$1fwd\$1writer\$1errors\$1session\$1limit |
| Aurora\$1fwd\$1master\$1errors\$1rpc\$1timeout | Aurora\$1fwd\$1writer\$1errors\$1rpc\$1timeout |
Aurora MySQL バージョン 3 では、次の設定パラメータに新しい名前が付けられました。
互換性のため、`mysql` クライアントのパラメータ値をチェックするには、Aurora MySQL バージョン 3 の初期のリリースでいずれかの名前を使用します。カスタムパラメータグループ内の値を変更する場合、新しい名前のみ使用できます。古いパラメータ名は、将来のリリースで削除される予定です。
| 削除される名前 | 新しい名前または優先される名 |
| --- | --- |
| aurora\$1fwd\$1master\$1idle\$1timeout | aurora\$1fwd\$1writer\$1idle\$1timeout |
| aurora\$1fwd\$1master\$1max\$1connections\$1pct | aurora\$1fwd\$1writer\$1max\$1connections\$1pct |
| master\$1verify\$1checksum | source\$1verify\$1checksum |
| sync\$1master\$1info | sync\$1source\$1info |
| init\$1slave | init\$1replica |
| rpl\$1stop\$1slave\$1timeout | rpl\$1stop\$1replica\$1timeout |
| log\$1slow\$1slave\$1statements | log\$1slow\$1replica\$1statements |
| slave\$1max\$1allowed\$1packet | replica\$1max\$1allowed\$1packet |
| slave\$1compressed\$1protocol | replica\$1compressed\$1protocol |
| slave\$1exec\$1mode | replica\$1exec\$1mode |
| slave\$1type\$1conversions | replica\$1type\$1conversions |
| slave\$1sql\$1verify\$1checksum | replica\$1sql\$1verify\$1checksum |
| slave\$1parallel\$1type | replica\$1parallel\$1type |
| slave\$1preserve\$1commit\$1order | replica\$1preserve\$1commit\$1order |
| log\$1slave\$1updates | log\$1replica\$1updates |
| slave\$1allow\$1batching | replica\$1allow\$1batching |
| slave\$1load\$1tmpdir | replica\$1load\$1tmpdir |
| slave\$1net\$1timeout | replica\$1net\$1timeout |
| sql\$1slave\$1skip\$1counter | sql\$1replica\$1skip\$1counter |
| slave\$1skip\$1errors | replica\$1skip\$1errors |
| slave\$1checkpoint\$1period | replica\$1checkpoint\$1period |
| slave\$1checkpoint\$1group | replica\$1checkpoint\$1group |
| slave\$1transaction\$1retries | replica\$1transaction\$1retries |
| slave\$1parallel\$1workers | replica\$1parallel\$1workers |
| slave\$1pending\$1jobs\$1size\$1max | replica\$1pending\$1jobs\$1size\$1max |
| pseudo\$1slave\$1mode | pseudo\$1replica\$1mode |
Aurora MySQL バージョン 3 では、次のストアドプロシージャは新しい名前になっています。
Aurora MySQL バージョン 3 の初期のリリースでは、互換性のためにいずれかの名前を使用できます。以前のプロシージャ名は、将来のリリースで削除される予定です。
| 削除される名前 | 新しい名前または優先される名 |
| --- | --- |
| mysql.rds\$1set\$1master\$1auto\$1position | mysql.rds\$1set\$1source\$1auto\$1position |
| mysql.rds\$1set\$1external\$1master | mysql.rds\$1set\$1external\$1source |
| mysql.rds\$1set\$1external\$1master\$1with\$1auto\$1position | mysql.rds\$1set\$1external\$1source\$1with\$1auto\$1position |
| mysql.rds\$1reset\$1external\$1master | mysql.rds\$1reset\$1external\$1source |
| mysql.rds\$1next\$1master\$1log | mysql.rds\$1next\$1source\$1log |
## AUTO\$1INCREMENT 値
Aurora MySQL バージョン 3 では、各 DB インスタンスを再起動する際、Aurora は 各テーブルの `AUTO_INCREMENT` 値を保持します。Aurora MySQL バージョン 2 では、再起動後に `AUTO_INCREMENT` 値が保持されませんでした。
スナップショットからの復元や、ポイントインタイムリカバリの実行、およびクラスターのクローン作成によって新しいクラスターを設定した場合、`AUTO_INCREMENT` 値は保持されません。この場合の `AUTO_INCREMENT` 値は、スナップショットが作成された時点のテーブル内の最大列値に基づいた値に初期化されます。この動作は、RDS for MySQL 8.0 では異なり、`AUTO_INCREMENT` 値はこれらのオペレーション中に保持されます。
## バイナリログレプリケーション
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 クラスターとの間のレプリケーション (バイナリログレプリケーション)](AuroraMySQL.Replication.MySQL.md) を参照してください。
Aurora MySQL バージョン 3 には、フィルタリングされたレプリケーションなど、コミュニティ MySQL 8.0 でのバイナリログレプリケーションの改善が含まれています。コミュニティ MySQL 8.0 の改善の詳細については、*MySQL リファレンスマニュアル*の[サーバーがレプリケーションフィルタ規則を評価する方法](https://dev.mysql.com/doc/refman/8.0/en/replication-rules.html)を参照してください。
### バイナリログレプリケーションのトランザクション圧縮
バイナリログ圧縮の使用方法については、MySQL リファレンスマニュアルの[バイナリログトランザクションの圧縮](https://dev.mysql.com/doc/refman/8.0/en/binary-log-transaction-compression.html)を参照してください。
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 のデータベースエンジンの更新](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraMySQLReleaseNotes/AuroraMySQL.Updates.30Updates.html)」を参照してください。
**Topics**
+ [MySQL 8.0 の機能はAurora MySQL バージョン 3 では利用できません](#AuroraMySQL.Compare-80-v3-features)
+ [ロールベースの特権モデル](#AuroraMySQL.privilege-model)
+ [データベースサーバー ID の確認](#AuroraMySQL.server-id)
+ [認証](#AuroraMySQL.mysql80-authentication)
## MySQL 8.0 の機能はAurora MySQL バージョン 3 では利用できません
コミュニティ MySQL 8.0 の次の機能は、Aurora MySQL バージョン 3 では利用できないか、異なる動作をします。
+ リソースグループと関連付けられた SQL ステートメントは、Aurora MySQL ではサポートされていません。
+ Aurora MySQL は、ユーザー定義の UNDO テーブルスペースおよび関連する SQL ステートメント (`CREATE UNDO TABLESPACE`、`ALTER UNDO TABLESPACE ... SET INACTIVE` および `DROP UNDO TABLESPACE` など) をサポートしていません。
+ Aurora MySQL は 3.06 より前のバージョンの Aurora MySQL の UNDO テーブルスペースの切り捨てをサポートしていません。Aurora MySQL バージョン 3.06 以降では、[UNDO テーブルスペースの自動切り捨て](https://dev.mysql.com/doc/refman/8.0/en/innodb-undo-tablespaces.html#truncate-undo-tablespace)がサポートされています。
+ パスワード検証プラグインがサポートされています。
+ パスワード検証プラグインを含め、MySQL プラグインの設定を変更することはできません。
+ X プラグインはサポートされていません。
+ マルチソースレプリケーションはサポートされません。
## ロールベースの特権モデル
Aurora MySQL バージョン 3 では、`mysql` データベースのテーブルを直接変更できません。特に、`mysql.user` テーブルへの挿入によるユーザ設定ができません。代わりに、SQL 文を使用してロールベースの権限を付与します。また、`mysql` データベースでストアドプロシージャなど、他の種類のオブジェクトを作成することはできません。`mysql` テーブルにクエリを実行することはできます。バイナリログ レプリケーションを使用する場合、出典 クラスターの `mysql` テーブルへの直接的な変更は、ターゲット クラスターにレプリケートされません。
場合によっては、`mysql` テーブルに挿入することで、アプリケーションがショートカットを使用して、ユーザーやその他のオブジェクトを作成する場合があります。その場合は、アプリケーションコードを変更して、`CREATE USER` などの対応したステートメントを使用します。アプリケーションが `mysql` データベースでストアドプロシージャまたはその他のオブジェクトを作成する場合は、代わりに別のデータベースを使用してください。
外部 MySQL データベースからの移行中にデータベースユーザーのメタデータをエクスポートするには、`mysqldump` の代わりに MySQL Shell コマンドを使用します。詳細については、「[インスタンスダンプユーティリティ、スキーマダンプユーティリティ、テーブルダンプユーティリティ](https://dev.mysql.com/doc/mysql-shell/8.0/en/mysql-shell-utilities-dump-instance-schema.html#mysql-shell-utilities-dump-about)」を参照してください。
多くのユーザーまたはアプリケーションの権限の管理を簡素化するには、`CREATE ROLE` ステートメントを使用して、一連の権限を持つロールを作成します。その後、`GRANT` および `SET ROLE` ステートメントと `current_role` 関数を使用して、ユーザーまたはアプリケーションにロールを割り当てたり、現在のロールを切り替えたり、有効なロールをチェックしたりできます。MySQL 8.0 でのロールベースのアクセス許可システムの詳細については、MySQL リファレンスマニュアルの[ロールの使用](https://dev.mysql.com/doc/refman/8.0/en/roles.html)を参照してください。
**重要**
アプリケーションではマスターユーザーを直接使用しないことを強くお勧めします。代わりに、アプリケーションに必要な最小の特権で作成されたデータベースユーザーを使用するというベストプラクティスに従ってください。
**Topics**
+ [rds\$1superuser\$1role](#AuroraMySQL.privilege-model.rds_superuser_role)
+ [バイナリログレプリケーションの権限チェックユーザー](#AuroraMySQL.privilege-model.binlog)
+ [他の AWS サービスにアクセスするためのロール](#AuroraMySQL.privilege-model.other)
### rds\$1superuser\$1role
Aurora MySQL バージョン 3 には、以下のすべての権限を持つ特別なロールが含まれています。ロールの名前は `rds_superuser_role` です。各クラスターのプライマリ管理ユーザーには、既にこのロールが付与されています。`rds_superuser_role` ロールには、すべてのデータベースオブジェクトに対する次の権限が含まれます。
+ `ALTER`
+ `APPLICATION_PASSWORD_ADMIN`
+ `ALTER ROUTINE`
+ `CONNECTION_ADMIN`
+ `CREATE`
+ `CREATE ROLE`
+ `CREATE ROUTINE`
+ `CREATE TEMPORARY TABLES`
+ `CREATE USER`
+ `CREATE VIEW`
+ `DELETE`
+ `DROP`
+ `DROP ROLE`
+ `EVENT`
+ `EXECUTE`
+ `FLUSH_OPTIMIZER_COSTS` (Aurora MySQL バージョン 3.09 以降)
+ `FLUSH_STATUS` (Aurora MySQL バージョン 3.09 以降)
+ `FLUSH_TABLES` (Aurora MySQL バージョン 3.09 以降)
+ `FLUSH_USER_RESOURCES` (Aurora MySQL バージョン 3.09 以降)
+ `INDEX`
+ `INSERT`
+ `LOCK TABLES`
+ `PROCESS`
+ `REFERENCES`
+ `RELOAD`
+ `REPLICATION CLIENT`
+ `REPLICATION SLAVE`
+ `ROLE_ADMIN`
+ `SET_USER_ID`
+ `SELECT`
+ `SHOW DATABASES`
+ `SHOW_ROUTINE` (Aurora MySQL バージョン 3.04 以降)
+ `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 には、バイナリログ (binlog) レプリケーションの権限チェックユーザー `rdsrepladmin_priv_checks_user` が含まれています。`rds_superuser_role` の権限に加えて、このユーザーには `replication_applier` 権限があります。
`mysql.rds_start_replication` ストアドプロシージャを呼び出してバイナリログレプリケーションを有効にすると、`rdsrepladmin_priv_checks_user` が作成されます。
`rdsrepladmin_priv_checks_user@localhost` ユーザーは予約済みユーザーです。変更しないでください。
### 他の AWS サービスにアクセスするためのロール
Aurora MySQL バージョン 3 には、他の AWS サービスにアクセスするために使用できるロールが含まれています。権限を付与する代わりに、これらのロールの多くを設定できます。例えば、`GRANT INVOKE LAMBDA ON *.* TO user` の代わりに `GRANT AWS_LAMBDA_ACCESS TO user` を指定します。他の AWS サービスにアクセスする手順については、[Amazon Aurora MySQL と他の AWS のサービスの統合](AuroraMySQL.Integrating.md) を参照してください。Aurora MySQLバージョン 3 には、他の AWS サービスへのアクセスに関連する次のロールが含まれています。
+ `AWS_LAMBDA_ACCESS` – `INVOKE LAMBDA` の権限の代替。使用に関する情報については、「[Amazon Aurora MySQL DB クラスターからの Lambda 関数の呼び出し](AuroraMySQL.Integrating.Lambda.md)」を参照してください。
+ `AWS_LOAD_S3_ACCESS` – `LOAD FROM S3` の権限の代替。使用に関する情報については、「[Amazon S3 バケットのテキストファイルから Amazon Aurora MySQL DB クラスターへのデータのロード](AuroraMySQL.Integrating.LoadFromS3.md)」を参照してください。
+ `AWS_SELECT_S3_ACCESS` – `SELECT INTO S3` の権限の代替。使用に関する情報については、「[Amazon Aurora MySQL DB クラスターから Amazon S3 バケット内のテキストファイルへのデータの保存](AuroraMySQL.Integrating.SaveIntoS3.md)」を参照してください。
+ `AWS_COMPREHEND_ACCESS` – `INVOKE COMPREHEND` の権限の代替。使用に関する情報については、「[データベースユーザーに Aurora 機械学習へのアクセスを許可する](mysql-ml.md#aurora-ml-sql-privileges)」を参照してください。
+ `AWS_SAGEMAKER_ACCESS` – `INVOKE SAGEMAKER` の権限の代替。使用に関する情報については、「[データベースユーザーに Aurora 機械学習へのアクセスを許可する](mysql-ml.md#aurora-ml-sql-privileges)」を参照してください。
+ `AWS_BEDROCK_ACCESS` – Amazon Bedrock には類似した `INVOKE` の権限はありません。使用に関する情報については、「[データベースユーザーに Aurora 機械学習へのアクセスを許可する](mysql-ml.md#aurora-ml-sql-privileges)」を参照してください。
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_SELECT_S3_ACCESS`@`%`,`rds_superuser_role`@`%` |
+-----------------------------------------------------+
```
## データベースサーバー ID の確認
バイナリログ (binlog) レプリケーションには、データベースサーバー ID (`server_id`) が必要です。サーバー ID を確認する方法は、Aurora MySQL とコミュニティ MySQL では異なります。
コミュニティ MySQL では、サーバー ID は数字であり、サーバーにログインしている間に次の構文を使用して取得します。
```
mysql> select @@server_id;
+-------------+
| @@server_id |
+-------------+
| 2 |
+-------------+
1 row in set (0.00 sec)
```
Aurora MySQL では、サーバー ID は DB インスタンス ID であり、DB インスタンスにログインしている間に次の構文を使用して取得します。
```
mysql> select @@aurora_server_id;
+------------------------+
| @@aurora_server_id |
+------------------------+
| mydbcluster-instance-2 |
+------------------------+
1 row in set (0.00 sec)
```
バイナリログレプリケーションの詳細については、「[Aurora と MySQL との間、または Aurora と別の Aurora DB クラスターとの間のレプリケーション (バイナリログレプリケーション)](AuroraMySQL.Replication.MySQL.md)」を参照してください。
## 認証
コミュニティ MySQL 8.0 では、デフォルトの認証プラグインは `caching_sha2_password` です。Aurora MySQL バージョン 3 では、依然として `mysql_native_password` プラグインを使用します。`default_authentication_plugin` 設定は変更できません。ただし、新しいユーザーの作成と現在のユーザーの変更は可能であり、個々のパスワードでは新しい認証プラグインを使用します。次に例を示します。
```
mysql> CREATE USER 'testnewsha'@'%' IDENTIFIED WITH caching_sha2_password BY 'aNewShaPassword';
Query OK, 0 rows affected (0.74 sec)
```
# Aurora MySQL バージョン 3 へのアップグレード
Aurora MySQL バージョン 2 からバージョン 3 にデータベースをアップグレードする方法については、「[Amazon Aurora MySQL DB クラスターのメジャーバージョンのアップグレード](AuroraMySQL.Updates.MajorVersionUpgrade.md)」を参照してください。