Amazon RDS for MySQL の既知の問題と制限 - Amazon Relational Database Service

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=72745http://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 ドキュメントの「インデックスマージの最適化」を参照してください。

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

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

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

ALTER TABLE table_name ENGINE=InnoDB;

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) に基づくレプリケーションをサポートしていません。

MySQL デフォルト認証プラグイン

RDS for MySQL バージョン 8.0.34 以降では、mysql_native_password プラグインを使用します。default_authentication_plugin 設定は変更できません。