コンソールにサインインする
Amazon Relational Database Service
ユーザーガイド (API バージョン 2014-10-31)

AWS ドキュメント » Amazon Relational Database Service (RDS) » ユーザーガイド » Amazon RDS での MySQL » Amazon RDS における MySQL の既知の問題と制限

Amazon RDS における MySQL の既知の問題と制限

Amazon RDS で 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 パラメータグループのパラメータの設定については、「DB パラメータグループを使用する」を参照してください。

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

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

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

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

ログファイルのサイズ

MySQL バージョン 5.6.20 以降では、REDO ログに書き込まれる BLOB にサイズ制限があります。この制限に対処するには、MySQL DB インスタンスの innodb_log_file_size パラメータを、テーブル内で最も大きい BLOB データサイズに、同テーブル内の他の可変長フィールド (VARCHAR、VARBINARY、TEXT) を足した長さより 10 倍大きくします。パラメータ値を設定する方法については、「DB パラメータグループを使用する」を参照してください。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 DB インスタンスのサポートされている値は、デフォルトの 0 ([names stored as given and comparisons are case-sensitive]) または 1 ([names stored in lowercase and comparisons are not case-sensitive]) です。

lower_case_table_names パラメータは、DB インスタンスの作成前に、カスタム DB パラメータグループに追加して設定する必要があります。既存のデータベースインスタンスの lower_case_table_names パラメータを変更しないでください。変更すると、ポイントインタイム復元のバックアップとリードレプリカの DB インスタンスで不整合が生じることがあるためです。

リードレプリカでは、常にマスター DB インスタンスと同じ lower_case_table_names パラメータ値を使用する必要があります。

long_query_time

long_query_time パラメータを浮動小数点値に設定することで、スロークエリを MySQL スロークエリログにマイクロ秒の精度で記録できます。たとえば、この値として 0.1 秒 (100 ミリ秒) を設定すると、1 秒未満のスロートランザクションのデバッグ時に役立ちます。

MySQL のファイルサイズの制限

Amazon RDS MySQL DB インスタンスの場合、InnoDB file-per-table テーブル領域を使用するとき、プロビジョンドストレージの最大サイズにより、テーブルのサイズは最大 16 TB に制限されます。また、システムのテーブルスペースも最大 16 TB に制限されています。テーブルがそれぞれに固有のテーブル領域に存在する InnoDB file-per-table テーブル領域は、Amazon RDS MySQL DB インスタンスに対してデフォルトで設定されます。

注記

既存の DB インスタンスに下限がある場合があります。たとえば、2014 年 4 月より前に作成された MySQL DB インスタンスには、2 TB のテーブルサイズの制限があります。この 2 TB というファイルサイズの制限は、2014 年 4 月より前に作成された DB スナップショットから作成された DB インスタンスまたはリードレプリカにも適用されます。その DB インスタンスがいつ作成されたかには関係ありません。

InnoDB file-per-table テーブルスペースの使用は、アプリケーションにより長所と短所があります。アプリケーションに最適な方法を判断するには、MySQL のドキュメントで「InnoDB File-Per-Table Mode」を参照してください。

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

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

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

  • 次の 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 に設定します。

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

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

ALTER TABLE table_name ENGINE=InnoDB;