Amazon RDS for MySQL の既知の問題と制限 - Amazon Relational Database Service
InnoDB 予約語ストレージ全体の動作InnoDB バッファプールサイズの不整合インデックスマージの最適化で誤った結果が返されるAmazon RDS DB インスタンスに使用する MySQL のパラメータの例外Amazon RDS での MySQL のファイルサイズ制限MySQL キーリングプラグインがサポートされていないカスタムポートMySQL ストアドプロシージャの制限事項外部ソースインスタンスを使用した GTID ベースのレプリケーションMySQL デフォルト認証プラグインinnodb_buffer_pool_size の上書きMySQL 5.7 から MySQL 8.4 へのアップグレードInnoDB ページ圧縮

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 インスタンスは自動的に再起動します。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 と http://bugs.mysql.com/bug.php?id=68194 を参照してください。

例えば、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 バージョン、およびバージョン 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_query_time

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」を参照してください。

注記

既存の 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 以降の 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 パラメータの値を変更します。詳細については、「デフォルトおよびカスタムパラメータグループ」を参照してください。

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

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 のメジャーバージョンのアップグレード」を参照してください。

InnoDB ページ圧縮

InnoDB ページ圧縮は、ファイルシステムのブロックサイズが 16k の Amazon RDS DB インスタンスでは機能しません。これは、ファイルシステムのブロックサイズが InnoDB ページサイズより小さくなければならないためです。2024 年 2 月以降、新しく作成されるすべての DB インスタンスのファイルシステムで、ブロックサイズは 16k になります。これにより、スループットが向上し、ページフラッシュ中の IOPS 消費量が減少します。