Amazon RDS for MySQL の既知の問題と制限 - Amazon Relational Database Service
InnoDB 予約語InnoDB バッファープールサイズの不整合インデックスマージの最適化で誤った結果が返されるログファイルのサイズAmazon RDS DB インスタンスに使用する MySQL のパラメータの例外Amazon RDS での MySQL のファイルサイズ制限MySQL キーリングプラグインがサポートされていない

Amazon RDS for MySQL の既知の問題と制限

Amazon RDS for MySQL を使用する際の既知の問題と制限は、以下のとおりです。

InnoDB 予約語

InnoDB は、RDS for MySQL の予約語です。MySQL データベースにこの名前を使用することはできません。

InnoDB バッファープールサイズの不整合

現在のところ、MySQL 5.7 には、InnoDB バッファープールサイズの管理方法にバグがあります。MySQL 5.7 が innodb_buffer_pool_size パラメータの値を大きな値に調整し、それにより InnoDB バッファープールが大きくなりすぎ、過度のメモリを使用する可能性があります。この影響により、MySQL データベースエンジンは実行を停止するか、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 パラメータグループのパラメータの設定については、「パラメータグループを使用する」を参照してください。

  • MySQL DB インスタンスを MySQL バージョン 5.7 または 8.0 にアップグレードします。詳細については、「MySQL DB スナップショットのアップグレード」を参照してください。

  • インスタンスをアップグレードできない場合や、optimizer_switch パラメータを変更できない場合は、明示的にクエリのインデックスを指定してバグを回避できます。例えば、次のように指定します。

    SELECT * FROM table1
USE INDEX covering_index
WHERE indexed_col1 = 'value1' AND indexed_col2 = 'value2';

詳細については、「インデックスマージの最適化」を参照してください。

ログファイルのサイズ

MySQL では、REDO ログに書き込まれる BLOB にサイズ制限があります。この制限に対処するには、MySQL DB インスタンスの innodb_log_file_size パラメータを、テーブル内で最も大きい BLOB データサイズに、同テーブル内の他の可変長フィールド (VARCHAR、VARBINARY、TEXT) を足した長さより 10 倍大きくします。パラメータ値を設定する方法については、「パラメータグループを使用する」を参照してください。REDO ログの BLOB サイズ制限の詳細については、「MySQL 5.6.20 の変更点」を参照してください。

Amazon RDS DB インスタンスに使用する MySQL のパラメータの例外

MySQL の一部のパラメータは、Amazon RDS DB インスタンスとともに使用する場合に、特別な考慮事項があります。

lower_case_table_names

Amazon RDS は、大文字と小文字が区別されるファイルシステムを使用するため、lower_case_table_names サーバーパラメータの値を 2 ([names stored as given but compared in lowercase]) に設定することはできません。以下は、Amazon RDS for MySQL インスタンスでサポートされている値です。

  • 0 (「指定された名前で保存され、比較では大文字と小文字が区別される」) は、すべての Amazon RDS for MySQL バージョンでサポートされています。

  • 1 (「名前は小文字で保存され、比較では大文字と小文字が区別されない」) は、RDS for MySQL バージョンのバージョン 5.7、バージョン 8.0.19、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 Tablespaces」を参照してください。

テーブルを最大ファイルサイズまで拡張可能にすることはお勧めしません。一般的に望ましいのは、データを小さなテーブルにパーティショニングすることです。これにより、パフォーマンスと復旧時間が改善される可能性があります。

大きなテーブルを小さなテーブルに分ける方法の 1 つはパーティション化です。パーティション化では、指定したルールに基づいて、大きなテーブルの各部分を個別のファイルに分散します。例えば、トランザクションを日付ごとに保存する場合、パーティション化を使用して古いトランザクションを別々のファイルに分散させるパーティションルールを作成できます。また、定期的に、アプリケーションですぐに使用する必要のない履歴トランザクションデータをアーカイブできます。詳細については、MySQL ドキュメントの「Partitioning」に移動してください。

テーブルのファイルサイズを確認するには

  • 次の SQL コマンドを使用して、パーティション化の対象になる過度に大きなテーブルがあるか判断します。

    SELECT TABLE_SCHEMA, TABLE_NAME,
round(((DATA_LENGTH + INDEX_LENGTH) / 1024 / 1024), 2) As "Approximate size (MB)"
FROM information_schema.TABLES
WHERE TABLE_SCHEMA NOT IN ('mysql', 'information_schema', 'performance_schema');

InnoDB file-per-table テーブルスペースを有効にするには

  • InnoDB file-per-table テーブルスペースを有効にするには、DB インスタンスのパラメータグループで innodb_file_per_table パラメータを 1 に設定します。

InnoDB file-per-table テーブルスペースを無効にするには

  • InnoDB file-per-table テーブルスペースを無効にするには、DB インスタンスのパラメータグループで innodb_file_per_table パラメータを 0 に設定します。

パラメータグループの更新については、「パラメータグループを使用する」を参照してください。

InnoDB file-per-table テーブルスペースを有効または無効にすると、次の例のように ALTER TABLE コマンドを実行してテーブルをグローバルテーブルスペースから固有のテーブルスペースに、または固有のテーブルスペースからグローバルテーブルスペースに移動できます。

ALTER TABLE table_name ENGINE=InnoDB;

MySQL キーリングプラグインがサポートされていない

現在、Amazon RDS for MySQL では、MySQL の Amazon Web Services のキーリングプラグイン keyring_aws をサポートしていません。