# Amazon RDS for MySQL の既知の問題と制限
Amazon RDS for MySQL を使用する際の既知の問題と制限は、以下のとおりです。
**Topics**
+ [
## InnoDB 予約語
](#MySQL.Concepts.KnownIssuesAndLimitations.InnodbDatabaseName)
+ [
## Amazon RDS for MySQL のストレージ全体の動作
](#MySQL.Concepts.StorageFullBehavior)
+ [
## InnoDB バッファプールサイズの不整合
](#MySQL.Concepts.KnownIssuesAndLimitations.InnodbBufferPoolSize)
+ [
## インデックスマージの最適化で誤った結果が返される
](#MySQL.Concepts.KnownIssuesAndLimitations.IndexMergeOptimization)
+ [
## Amazon RDS DB インスタンスに使用する MySQL のパラメータの例外
](#MySQL.Concepts.ParameterNotes)
+ [
## Amazon RDS での MySQL のファイルサイズ制限
](#MySQL.Concepts.Limits.FileSize)
+ [
## MySQL キーリングプラグインがサポートされていない
](#MySQL.Concepts.Limits.KeyRing)
+ [
## カスタムポート
](#MySQL.Concepts.KnownIssuesAndLimitations.CustomPorts)
+ [
## MySQL ストアドプロシージャの制限事項
](#MySQL.Concepts.KnownIssuesAndLimitations.KillProcedures)
+ [
## 外部ソースインスタンスを使用した GTID ベースのレプリケーション
](#MySQL.Concepts.KnownIssuesAndLimitations.GTID)
+ [
## MySQL デフォルト認証プラグイン
](#MySQL.Concepts.KnownIssuesAndLimitations.authentication-plugin)
+ [
## innodb\$1buffer\$1pool\$1size の上書き
](#MySQL.Concepts.KnownIssuesAndLimitations.innodb-bp-size)
+ [
## MySQL 5.7 から MySQL 8.4 へのアップグレード
](#MySQL.Concepts.KnownIssuesAndLimitations.upgrade-8-4)
+ [
## InnoDB ページ圧縮
](#MySQL.Concepts.KnownIssuesAndLimitations.innodb-page-compression)
## InnoDB 予約語
`InnoDB` は、RDS for MySQL の予約語です。MySQL データベースにこの名前を使用することはできません。
## Amazon RDS for MySQL のストレージ全体の動作
MySQL DB インスタンスのストレージがいっぱいになると、メタデータの不一致、ディクショナリの不一致、孤立テーブルが発生する可能性があります。これらの問題を回避するために、Amazon RDS は `storage-full` 状態に達する DB インスタンスを自動的に停止します。
MySQL DB インスタンスは、次の場合に `storage-full` 状態に達します。
+ DB インスタンスのストレージは 20,000 MiB 未満で、使用可能なストレージは 200 MiB 以下です。
+ DB インスタンスのストレージは 102,400 MiB 超で、使用可能なストレージは 1024 MiB 以下です。
+ DB インスタンスのストレージは 20,000 MiB～102,400 MiB で、使用可能なストレージの 1% 未満です。
DB インスタンスが `storage-full` 状態に達したために Amazon RDS がそのインスタンスを自動的に停止した後でも、そのインスタンスを変更できます。DB インスタンスを再起動するには、次のうち少なくとも 1 つを実行します。
+ DB インスタンスを変更して、ストレージのオートスケーリングを有効にします。
ストレージのオートスケーリングの詳細については、[Amazon RDS ストレージの自動スケーリングによる容量の自動管理](USER_PIOPS.Autoscaling.md) を参照してください。
+ ストレージ容量を増やすには、DB インスタンスを変更します。
ストレージ容量の引き上げの詳細については、[DB インスタンスストレージの容量を増加する](USER_PIOPS.ModifyingExisting.md) を参照してください。
これらの変更のいずれかを行うと、DB インスタンスは自動的に再起動します。DB インスタンスの変更については、[Amazon RDS DB インスタンスを変更する](Overview.DBInstance.Modifying.md)を参照してください。
## InnoDB バッファプールサイズの不整合
現在のところ、MySQL 5.7 には、InnoDB バッファプールサイズの管理方法にバグがあります。MySQL 5.7 が `innodb_buffer_pool_size` パラメータの値を大きな値に調整し、それにより InnoDB バッファプールが大きくなりすぎ、過度のメモリを使用する可能性があります。この影響により、MySQL データベースエンジンは実行を停止するか、起動できなくなる場合があります。この問題は、使用できるメモリが少ない DB インスタンスクラスでより多く発生します。
この問題を解決するには、`innodb_buffer_pool_size` パラメータの値を、`innodb_buffer_pool_instances` パラメータの値と `innodb_buffer_pool_chunk_size` パラメータの値の積の倍数に設定します。例えば、次の例に示すように、`innodb_buffer_pool_size` パラメータの値を `innodb_buffer_pool_instances` および `innodb_buffer_pool_chunk_size` パラメータの積の 8 倍に設定します。
```
innodb_buffer_pool_chunk_size = 536870912
innodb_buffer_pool_instances = 4
innodb_buffer_pool_size = (536870912 * 4) * 8 = 17179869184
```
この MySQL 5.7 のバグの詳細については、MySQL ドキュメントの [https://bugs.mysql.com/bug.php?id=79379](https://bugs.mysql.com/bug.php?id=79379) を参照してください。
## インデックスマージの最適化で誤った結果が返される
インデックスマージの最適化を使用するクエリは、MySQL 5.5.37 で導入された MySQL クエリオプティマイザのバグのために誤った結果を返す場合があります。複数のインデックスを持つテーブルに対してクエリを実行すると、オプティマイザは複数のインデックスに基づいて行の範囲をスキャンしますが、結果を正しくマージしません。クエリのクエリオプティマイザのバグの詳細については、MySQL バグデータベースの [http://bugs.mysql.com/bug.php?id=72745](https://bugs.mysql.com/bug.php?id=72745) と [http://bugs.mysql.com/bug.php?id=68194](https://bugs.mysql.com/bug.php?id=68194) を参照してください。
例えば、2 つのインデックスを持つテーブルで、検索引数がインデックス付き列を参照するクエリがあるとします。
```
1. SELECT * FROM table1
2. WHERE indexed_col1 = 'value1' AND indexed_col2 = 'value2';
```
この場合、検索エンジンは両方のインデックスを検索します。ただし、バグが原因で、マージされた結果は正しくありません。
この問題を解決するには、次のいずれかを実行します。
+ MySQL DB インスタンスの DB パラメータグループで `optimizer_switch` パラメータを `index_merge=off` に設定します。DB パラメータグループのパラメータの設定については、「[Amazon RDS のパラメータグループ](USER_WorkingWithParamGroups.md)」を参照してください。
+ MySQL DB インスタンスを MySQL バージョン 5.7 または 8.0 にアップグレードします。詳細については、「[RDS for MySQL DB エンジンのアップグレード](USER_UpgradeDBInstance.MySQL.md)」を参照してください。
+ インスタンスをアップグレードできない場合や、`optimizer_switch` パラメータを変更できない場合は、明示的にクエリのインデックスを指定してバグを回避できます。例えば、次のように指定します。
```
1. SELECT * FROM table1
2. USE INDEX covering_index
3. WHERE indexed_col1 = 'value1' AND indexed_col2 = 'value2';
```
詳細については、MySQL ドキュメントの「[インデックスマージの最適化](https://dev.mysql.com/doc/refman/8.0/en/index-merge-optimization.html)」を参照してください。
## Amazon RDS DB インスタンスに使用する MySQL のパラメータの例外
MySQL の一部のパラメータは、Amazon RDS DB インスタンスとともに使用する場合に、特別な考慮事項があります。
### lower\$1case\$1table\$1names
Amazon RDS は、大文字と小文字を区別するファイルシステムを使用するため、`lower_case_table_names` サーバーパラメータの値を 2 (名前は指定されたとおりに保存されるが、小文字で比較される) に設定することはできません。以下は、Amazon RDS for MySQL インスタンスでサポートされている値です。
+ 0 (名前は指定されたとおりに保存され、比較では大文字と小文字が区別される) は、すべての RDS for MySQL バージョンでサポートされています。
+ 1 (名前は小文字で保存され、比較では大文字と小文字が区別されない) は、RDS for MySQL バージョン 5.7、バージョン 8.0.28 以降の 8.0 バージョン、およびバージョン 8.4 でサポートされています。
DB インスタンスを作成する前に、カスタム DB パラメータグループに `lower_case_table_names` パラメータを設定します。その後、DB インスタンスを作成する際にカスタム DB パラメータグループを指定します。
パラメータグループが 8.0 より低いバージョンの MySQL DB インスタンスに関連付けられている場合、`lower_case_table_names` パラメータを変更しないことをお勧めします。これを変更すると、ポイントインタイムリカバリのバックアップとリードレプリカの DB インスタンスで不整合が生じることがあります。
パラメータグループがバージョン 8.0 または 8.4 の MySQL DB インスタンスに関連付けられている場合、`lower_case_table_names` パラメータを変更できません。
リードレプリカでは、常にマスター DB インスタンスと同じ `lower_case_table_names` パラメータ値を使用する必要があります。
### long\$1query\$1time
`long_query_time` パラメータを浮動小数点値に設定することで、スロークエリを MySQL スロークエリログにマイクロ秒の精度で記録できます。例えば、この値として 0.1 秒 (100 ミリ秒) を設定すると、1 秒未満のスロートランザクションのデバッグ時に役立ちます。
## Amazon RDS での MySQL のファイルサイズ制限
MySQL バージョン 8.0 以降の DB インスタンスの場合、最大ファイルサイズは 16 TiB です。file-per-table テーブルスペースを使用する場合、最大ファイルサイズにより、InnoDB テーブルのサイズは 16 TiB に制限されます。テーブルがそれぞれに固有のテーブル領域に存在する InnoDB file-per-table テーブル領域は、MySQL DB インスタンスに対してデフォルトで設定されます。詳細については、MySQL ドキュメントの「[InnoDB Limits](https://dev.mysql.com/doc/refman/8.0/en/innodb-limits.html)」を参照してください。
**注記**
既存の DB インスタンスには制限値がより低い場合があります。例えば、2014 年 4 月より前に作成された MySQL DB インスタンスの場合、テーブルサイズの上限は 2 TB です。この 2 TB というファイルサイズの制限は、2014 年 4 月より前に作成された DB スナップショットから作成された DB インスタンスまたはリードレプリカにも適用されます。その DB インスタンスがいつ作成されたかには関係ありません。
InnoDB file-per-table テーブルスペースの使用は、アプリケーションにより長所と短所があります。アプリケーションに最適な方法を判断するには、MySQL ドキュメントの「[File-Per-Table テーブルスペース](https://dev.mysql.com/doc/refman/8.0/en/innodb-file-per-table-tablespaces.html)」を参照してください。
テーブルを最大ファイルサイズまで拡張可能にすることはお勧めしません。一般的に望ましいのは、データを小さなテーブルにパーティショニングすることです。これにより、パフォーマンスと復旧時間が改善される可能性があります。
大きなテーブルを小さなテーブルに分ける方法の 1 つはパーティション化です。パーティション化は、指定したルールに基づいて、大きなテーブルの各部分を個別のファイルに分散します。例えば、トランザクションを日付ごとに保存する場合、パーティション化を使用して古いトランザクションを別々のファイルに分散させるパーティションルールを作成できます。また、定期的に、アプリケーションですぐに使用する必要のない履歴トランザクションデータをアーカイブできます。詳細については、MySQL ドキュメントの「[Partitioning](https://dev.mysql.com/doc/refman/8.0/en/partitioning.html)」を参照してください。
すべてのテーブルと InnoDB システムテーブルスペースのサイズを提供する単一のシステムテーブルまたはビューはないため、テーブルスペースのサイズを決定するには複数のテーブルをクエリする必要があります。
**InnoDB システムテーブルスペースとデータディクショナリテーブルスペースのサイズを確認するには**
+ 次の SQL コマンドを使用して、パーティション化の対象になる過度に大きなテーブルスペースがあるかどうかを確認します。
**注記**
データディクショナリテーブルスペースは MySQL 8.0 以降のバージョンに固有です。
```
1. select FILE_NAME,TABLESPACE_NAME, ROUND(((TOTAL_EXTENTS*EXTENT_SIZE)
2. /1024/1024/1024), 2) as "File Size (GB)" from information_schema.FILES
3. where tablespace_name in ('mysql','innodb_system');
```
**InnoDB システムテーブルスペース外の InnoDB ユーザーテーブルのサイズを確認するには (MySQL 5.7 バージョンの場合)**
+ 次の SQL コマンドを使用して、パーティション化の対象になる過度に大きなテーブルがあるか判断します。
```
1. SELECT SPACE,NAME,ROUND((ALLOCATED_SIZE/1024/1024/1024), 2)
2. as "Tablespace Size (GB)"
3. FROM information_schema.INNODB_SYS_TABLESPACES ORDER BY 3 DESC;
```
**InnoDB システムテーブルスペース外の InnoDB ユーザーテーブルのサイズを確認するには (MySQL 8.0 以降のバージョンの場合)**
+ 次の SQL コマンドを使用して、パーティション化の対象になる過度に大きなテーブルがあるか判断します。
```
1. SELECT SPACE,NAME,ROUND((ALLOCATED_SIZE/1024/1024/1024), 2)
2. as "Tablespace Size (GB)"
3. FROM information_schema.INNODB_TABLESPACES ORDER BY 3 DESC;
```
**InnoDB 以外のユーザーテーブルのサイズを確認するには**
+ 次の SQL コマンドを使用して、InnoDB 以外のユーザーテーブルが過度に大きいかどうかを確認します。
```
SELECT TABLE_SCHEMA, TABLE_NAME, round(((DATA_LENGTH + INDEX_LENGTH+DATA_FREE)
/ 1024 / 1024/ 1024), 2) As "Approximate size (GB)" FROM information_schema.TABLES
WHERE TABLE_SCHEMA NOT IN ('mysql', 'information_schema', 'performance_schema')
and ENGINE<>'InnoDB';
```
**InnoDB file-per-table テーブルスペースを有効にするには**
+ DB インスタンスのパラメータグループの *innodb\$1file\$1per\$1table* パラメータを `1` に設定します。
**InnoDB file-per-table テーブルスペースを無効にするには**
+ DB インスタンスのパラメータグループの *innodb\$1file\$1per\$1table* パラメータを `0` に設定します。
パラメータグループの更新については、「[Amazon RDS のパラメータグループ](USER_WorkingWithParamGroups.md)」を参照してください。
InnoDB file-per-table テーブルスペースを有効または無効にすると、次の例のように `ALTER TABLE` コマンドを実行してテーブルをグローバルテーブルスペースから固有のテーブルスペースに、または固有のテーブルスペースからグローバルテーブルスペースに移動できます。
```
ALTER TABLE table_name TABLESPACE=innodb_file_per_table;
```
## MySQL キーリングプラグインがサポートされていない
現在、Amazon RDS for MySQL では、MySQL `keyring_aws` Amazon Web Services のキーリングプラグインをサポートしていません。
## カスタムポート
Amazon RDS は MySQL エンジンのカスタムポート 33060 への接続をブロックします。MySQL エンジン用に別のポートを選択してください。
## MySQL ストアドプロシージャの制限事項
[mysql.rds\$1kill](mysql-stored-proc-ending.md#mysql_rds_kill) および [mysql.rds\$1kill\$1query](mysql-stored-proc-ending.md#mysql_rds_kill_query) ストアドプロシージャでは、以下の RDS for MySQL バージョンで、ユーザー名が 16 文字を超える MySQL ユーザーが所有するセッションやクエリは終了できません。
+ 8.0.32 以前の 8 バージョン
+ 5.7.41 以前の 5.7 バージョン
## 外部ソースインスタンスを使用した GTID ベースのレプリケーション
Amazon RDS は、設定時に GTID\$1PURGED の設定を必要とする外部 MySQL インスタンスから Amazon RDS for MySQL DB インスタンスへのグローバルなトランザクション識別子 (GTID) に基づくレプリケーションをサポートしています。ただし、この機能をサポートしているのは RDS for MySQL 8.0.37 以降のバージョンのみです。
## MySQL デフォルト認証プラグイン
RDS for MySQL バージョン 8.0.34 以降の 8.0 バージョンでは、`mysql_native_password` プラグインを使用します。`default_authentication_plugin` 設定は変更できません。
RDS for MySQL バージョン 8.4 以降のバージョンでは、`caching_sha2_password` プラグインをデフォルトの認証プラグインとして使用します。MySQL 8.4 のデフォルトの認証プラグインを変更できます。`mysql_native_password` プラグインは MySQL 8.4 でも動作しますが、このプラグインのサポートは MySQL 8.4 で終了します。デフォルトの認証プラグインを変更するには、カスタムパラメータグループを作成し、`authentication_policy` パラメータの値を変更します。詳細については、「[デフォルトおよびカスタムパラメータグループ](parameter-groups-overview.md#parameter-groups-overview.custom)」を参照してください。
## innodb\$1buffer\$1pool\$1size の上書き
マイクロ DB インスタンスクラスまたはスモール DB インスタンスクラスでは、`innodb_buffer_pool_size` パラメータのデフォルト値は、次のコマンドを実行して返される値とは異なる場合があります。
```
mysql> SELECT @@innodb_buffer_pool_size;
```
この違いは、DB インスタンスクラスの管理の一部として Amazon RDS がデフォルト値を上書きする必要がある場合に発生する可能性があります。必要に応じて、デフォルト値を上書きし、DB インスタンスクラスがサポートする値に設定できます。有効な値は、DB インスタンスで使用可能なメモリ使用量と合計メモリを足して決定します。詳細については、「[Amazon RDS インスタンスタイプ](https://aws.amazon.com/rds/instance-types/)」を参照してください。
DB インスタンスのメモリが 4 GB しかない場合、`innodb_buffer_pool_size` を 8 GB に設定することはできませんが、他のパラメータに割り当てたメモリの量によっては、3 GB に設定できる場合があります。
入力した値が大きすぎる場合、Amazon RDS は次の制限に従って値を引き下げます。
+ Micro DB インスタンスクラス: 256 MB
+ db.t4g.micro DB インスタンスクラス: 128 MB
## MySQL 5.7 から MySQL 8.4 へのアップグレード
MySQL 5.7 から MySQL 8.4 に直接アップグレードすることはできません。最初に MySQL 5.7 から MySQL 8.0 にアップグレードし、その後で MySQL 8.0 から MySQL 8.4 にアップグレードする必要があります。詳細については、「[RDS for MySQL のメジャーバージョンのアップグレード](USER_UpgradeDBInstance.MySQL.Major.md)」を参照してください。
## InnoDB ページ圧縮
InnoDB ページ圧縮は、ファイルシステムのブロックサイズが 16k の Amazon RDS DB インスタンスでは機能しません。これは、ファイルシステムのブロックサイズが InnoDB ページサイズより小さくなければならないためです。2024 年 2 月以降、新しく作成されるすべての DB インスタンスのファイルシステムで、ブロックサイズは 16k になります。これにより、スループットが向上し、ページフラッシュ中の IOPS 消費量が減少します。