Amazon RDS for MySQL の既知の問題と制限
Amazon RDS for MySQL を使用する際の既知の問題と制限は、以下のとおりです。
トピック
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 ストレージの自動スケーリングによる容量の自動管理 を参照してください。
-
ストレージ容量を増やすには、DB インスタンスを変更します。
ストレージ容量の引き上げの詳細については、DB インスタンスストレージの容量を増加する を参照してください。
これらの変更のいずれかを行うと、DB インスタンスは自動的に再起動します。DB インスタンスの変更については、「Amazon RDS DB インスタンスを変更する」を参照してください。
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
インデックスマージの最適化で誤った結果が返される
インデックスマージの最適化を使用するクエリは、MySQL 5.5.37 で導入された MySQL クエリオプティマイザのバグのために誤った結果を返す場合があります。複数のインデックスを持つテーブルに対してクエリを実行すると、オプティマイザは複数のインデックスに基づいて行の範囲をスキャンしますが、結果を正しくマージしません。クエリのクエリオプティマイザのバグの詳細については、MySQL バグデータベースの http://bugs.mysql.com/bug.php?id=72745
例えば、2 つのインデックスを持つテーブルで、検索引数がインデックス付き列を参照するクエリがあるとします。
SELECT * FROM table1 WHERE indexed_col1 = 'value1' AND indexed_col2 = 'value2';
この場合、検索エンジンは両方のインデックスを検索します。ただし、バグが原因で、マージされた結果は正しくありません。
この問題を解決するには、次のいずれかを実行します。
MySQL DB インスタンスの DB パラメータグループで
optimizer_switch
パラメータをindex_merge=off
に設定します。DB パラメータグループのパラメータの設定については、「Amazon RDS のパラメータグループ」を参照してください。-
MySQL DB インスタンスを MySQL バージョン 5.7 または 8.0 にアップグレードします。詳しくは、「RDS for MySQL DB エンジンのアップグレード」を参照してください。
-
インスタンスをアップグレードできない場合や、
optimizer_switch
パラメータを変更できない場合は、明示的にクエリのインデックスを指定してバグを回避できます。例えば、次のように指定します。SELECT * FROM table1 USE INDEX covering_index WHERE indexed_col1 = 'value1' AND indexed_col2 = 'value2';
詳細については、MySQL ドキュメントの「インデックスマージの最適化
Amazon RDS DB インスタンスに使用する MySQL のパラメータの例外
MySQL の一部のパラメータは、Amazon RDS DB インスタンスとともに使用する場合に、特別な考慮事項があります。
lower_case_table_names
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 バージョンでサポートされています。
DB インスタンスを作成する前に、カスタム DB パラメータグループに lower_case_table_names
パラメータを設定します。その後、DB インスタンスを作成する際にカスタム DB パラメータグループを指定します。
パラメータグループが 8.0 より低いバージョンの MySQL DB インスタンスに関連付けられている場合、lower_case_table_names
パラメータを変更しないことをお勧めします。これを変更すると、ポイントインタイムリカバリのバックアップとリードレプリカの DB インスタンスで不整合が生じることがあります。
パラメータグループがバージョン 8.0 MySQL DB インスタンスに関連付けられている場合、lower_case_table_names
パラメータを変更できません。
リードレプリカでは、常にマスター DB インスタンスと同じ lower_case_table_names
パラメータ値を使用する必要があります。
long_query_time
long_query_time
パラメータを浮動小数点値に設定することで、スロークエリを MySQL スロークエリログにマイクロ秒の精度で記録できます。例えば、この値として 0.1 秒 (100 ミリ秒) を設定すると、1 秒未満のスロートランザクションのデバッグ時に役立ちます。
Amazon RDS での MySQL のファイルサイズ制限
MySQL DB インスタンスの場合、InnoDB file-per-table テーブル領域を使用するとき、プロビジョンドストレージの最大サイズにより、テーブルのサイズは最大 16 TB に制限されます。また、システムのテーブルスペースも最大 16 TB に制限されています。テーブルがそれぞれに固有のテーブル領域に存在する InnoDB file-per-table テーブル領域は、MySQL DB インスタンスに対してデフォルトで設定されます。
注記
既存の DB インスタンスには制限値がより低い場合があります。例えば、2014 年 4 月より前に作成された MySQL DB インスタンスの場合、テーブルサイズの上限は 2 TB です。この 2 TB というファイルサイズの制限は、2014 年 4 月より前に作成された DB スナップショットから作成された DB インスタンスまたはリードレプリカにも適用されます。その DB インスタンスがいつ作成されたかには関係ありません。
InnoDB file-per-table テーブルスペースの使用は、アプリケーションにより長所と短所があります。アプリケーションに最適な方法を判断するには、MySQL ドキュメントの「File-Per-Table テーブルスペース
テーブルを最大ファイルサイズまで拡張可能にすることはお勧めしません。一般的に望ましいのは、データを小さなテーブルにパーティショニングすることです。これにより、パフォーマンスと復旧時間が改善される可能性があります。
大きなテーブルを小さなテーブルに分ける方法の 1 つはパーティション化です。パーティション化では、指定したルールに基づいて、大きなテーブルの各部分を個別のファイルに分散します。例えば、トランザクションを日付ごとに保存する場合、パーティション化を使用して古いトランザクションを別々のファイルに分散させるパーティションルールを作成できます。また、定期的に、アプリケーションですぐに使用する必要のない履歴トランザクションデータをアーカイブできます。詳細については、MySQL ドキュメントの「Partitioning
すべてのテーブルと InnoDB システムテーブルスペースのサイズを提供する単一のシステムテーブルまたはビューはないため、テーブルスペースのサイズを決定するには複数のテーブルをクエリする必要があります。
InnoDB システムテーブルスペースとデータディクショナリテーブルスペースのサイズを確認するには
-
次の SQL コマンドを使用して、パーティション化の対象になる過度に大きなテーブルスペースがあるかどうかを確認します。
注記
データディクショナリテーブルスペースは MySQL 8.0 に固有です。
select FILE_NAME,TABLESPACE_NAME, ROUND(((TOTAL_EXTENTS*EXTENT_SIZE) /1024/1024/1024), 2) as "File Size (GB)" from information_schema.FILES where tablespace_name in ('mysql','innodb_system');
InnoDB システムテーブルスペース外の InnoDB ユーザーテーブルのサイズを確認するには (MySQL 5.7 バージョンの場合)
-
次の SQL コマンドを使用して、パーティション化の対象になる過度に大きなテーブルがあるか判断します。
SELECT SPACE,NAME,ROUND((ALLOCATED_SIZE/1024/1024/1024), 2) as "Tablespace Size (GB)" FROM information_schema.INNODB_SYS_TABLESPACES ORDER BY 3 DESC;
InnoDB システムテーブルスペース外の InnoDB ユーザーテーブルのサイズを確認するには (MySQL 8.0 バージョンの場合)
-
次の SQL コマンドを使用して、パーティション化の対象になる過度に大きなテーブルがあるか判断します。
SELECT SPACE,NAME,ROUND((ALLOCATED_SIZE/1024/1024/1024), 2) as "Tablespace Size (GB)" 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_file_per_table パラメータを
1
に設定します。
InnoDB file-per-table テーブルスペースを無効にするには
-
DB インスタンスのパラメータグループの innodb_file_per_table パラメータを
0
に設定します。
パラメータグループの更新については、「Amazon RDS のパラメータグループ」を参照してください。
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_kill および mysql.rds_kill_query ストアドプロシージャでは、以下の RDS for MySQL バージョンで、ユーザー名が 16 文字を超える MySQL ユーザーが所有するセッションやクエリは終了できません。
-
8.0.32 以前の 8 バージョン
-
5.7.41 以前の 5.7 バージョン
外部ソースインスタンスを使用した GTID ベースのレプリケーション
Amazon RDS は、設定時に GTID_PURGED の設定を必要とする外部 MySQL インスタンスから Amazon RDS for MySQL DB インスタンスへのグローバルなトランザクション識別子 (GTID) に基づくレプリケーションをサポートしています。ただし、この機能をサポートしているのは RDS for MySQL 8.0.37 以降のバージョンのみです。
MySQL デフォルト認証プラグイン
RDS for MySQL バージョン 8.0.34 以降では、mysql_native_password
プラグインを使用します。default_authentication_plugin
設定は変更できません。
innodb_buffer_pool_size の上書き
マイクロ DB インスタンスクラスまたはスモール DB インスタンスクラスでは、innodb_buffer_pool_size
パラメータのデフォルト値は、次のコマンドを実行して返される値とは異なる場合があります。
mysql> SELECT @@innodb_buffer_pool_size;
この違いは、DB インスタンスクラスの管理の一部として Amazon RDS がデフォルト値を上書きする必要がある場合に発生する可能性があります。必要に応じて、デフォルト値を上書きし、DB インスタンスクラスがサポートする値に設定できます。有効な値は、DB インスタンスで使用可能なメモリ使用量と合計メモリを足して決定します。詳細については、「Amazon RDS インスタンスタイプ
DB インスタンスのメモリが 4 GB しかない場合、innodb_buffer_pool_size
を 8 GB に設定することはできませんが、他のパラメータに割り当てたメモリの量によっては、3 GB に設定できる場合があります。
入力した値が大きすぎる場合、Amazon RDS は次の制限に従って値を引き下げます。
-
Micro DB インスタンスクラス: 256 MB
-
db.t4g.micro DB インスタンスクラス: 128 MB