Amazon RDS での MySQL

2016 年 11 月 6 日に、Amazon RDS では MySQL バージョン 5.1 のサポートを終了します。2013 年 12 月に、MySQL Community Edition 5.1 は新しいソフトウェア、セキュリティの修正、更新を行わない継続サポートに移動しました。AWS をご利用のお客様に最適なエクスペリエンスを提供するために、バージョン 5.1 は廃止されます。

2016 年 10 月 18 日までに、MySQL バージョン 5.1 を実行している DB インスタンスを、MySQL のサポートされているバージョンのいずれかにアップグレードすることをお勧めします。Amazon RDS では、MySQL バージョン 5.5、5.6、および 5.7 がサポートされています。

MySQL バージョン 5.1 を実行する DB インスタンスをアップグレードする前に、MySQL データベースエンジンのサポートされているバージョンを実行する DB インスタンスを作成して、その DB インスタンスでアプリケーションをテストすることもできます。

以下のサイトで MySQL のサポートされているバージョンに関するリリースノートを確認できます。

MySQL バージョン 5.6 に DB インスタンスをアップグレードする場合は、まず DB インスタンスを MySQL バージョン 5.5 にアップグレードしてから、MySQL バージョン 5.6 にアップグレードする必要があります。MySQL バージョン 5.7 にアップグレードする場合は、まず DB インスタンスを MySQL バージョン 5.5 にアップグレードしてから、次にバージョン 5.6、それからバージョン 5.7 にアップグレードする必要があります。

DB インスタンスを MySQL の新しいバージョンにアップグレードする手順については、「MySQL DB エンジンのアップグレード」を参照してください。

Amazon RDS は、次のスケジュールで MySQL バージョン 5.1 のサポートを廃止します。

ほとんどの Amazon RDS DB エンジンでは、DB インスタンスの追加機能を選択できる、オプショングループをサポートしています。MySQL バージョン 5.6 以降の DB インスタンスは、シンプルなキーベースのキャッシュである memcached オプションをサポートします。memcached オプションの詳細については、「付録: MySQL データベースエンジンのオプション」を参照してください。オプショングループの操作方法の詳細については、「オプショングループを使用する」を参照してください。

Amazon RDS では、MySQL データベースエンジンを実行する DB インスタンスとの SSL 接続がサポートされています。

Amazon RDS によって、Amazon RDS インスタンスのプロビジョニング時、SSL 証明書が作成され、DB インスタンスにインストールされます。これらの証明書は認証局によって署名されます。SSL 証明書には、なりすまし攻撃から保護するために、SSL 証明書の共通名（CN）として DB インスタンスのエンドポイントが含まれています。パブリックキーは https://s3.amazonaws.com/rds-downloads/rds-combined-ca-bundle.pem にあります。

Amazon RDS によって作成された SSL 証明書は信頼されたルートエンティティであり、ほとんどの場合は使用できますが、アプリケーションが証明書チェーンを受け入れていない場合は使用できない可能性があります。アプリケーションが証明書チェーンを受け入れていない場合は、リージョンに接続している中間証明書の使用が必要になる場合があります。 たとえば、SSL を使用して GovCloud (米国) リージョンに接続するために、中間証明書を使用する必要があります。 ダウンロードできるリージョンの中間証明書のリストについては、「中間証明書」を参照してください。

デフォルトの mysql クライアントを使用して接続を暗号化するには、以下の例のように、--ssl-ca parameter でパブリックキーを参照して mysql クライアントを起動します。

mysql -h myinstance.c9akciq32.rds-us-east-1.amazonaws.com
    --ssl-ca=[full path]rds-combined-ca-bundle.pem --ssl-verify-server-cert

GRANT ステートメントを使用して、特定のユーザーアカウントに SSL 接続を求めることができます。たとえば、以下のステートメントを使用して、ユーザーアカウント encrypted_user に SSL 接続を求めることができます。

 GRANT USAGE ON *.* TO 'encrypted_user'@'%' REQUIRE SSL 

MySQL バージョン 5.6.19 以降の場合、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 を参照してください。

memcached インターフェイスは、MySQL バージョン 5.6.21b 以降でのみ使用することをお勧めします。これは、バージョン 5.6.21b 以降、MySQL エンジンに含まれる memcached インターフェイスに関連する多くのバグが修正されているからです。詳細については、MySQL のドキュメントの「MySQL 5.6.20 (2014-07-31) の変更点」と「MySQL 5.6.21 (2014-09-23) の変更点」を参照してください。

Amazon RDS 上の MySQL とともに memcached を使用する方法については、「MySQL の memcached サポート」を参照してください。

2014 年 4 月 23 日より前に作成され、2014 年 10 月 17 日以降に MySQL バージョン 5.5.40 にアップグレードした MySQL DB インスタンスでは、I/O パフォーマンスの低下が見られる場合があります。このパフォーマンスの低下は、対応する DB パラメータグループで innodb_use_native_aio パラメータを有効にしている場合でも、innodb_use_native_aio パラメータを無効にするエラーによって発生している可能性があります。

このエラーを解決するには、バージョン 5.5.40 を実行している MySQL DB インスタンスを、この動作を修正するバージョン 5.5.40a にアップグレードすることをお勧めします。マイナーバージョンのアップグレードについては、「MySQL DB エンジンのアップグレード」を参照してください。

MySQL の非同期 I/O の詳細については、MySQL のドキュメントの「Linux での非同期 I/O」を参照してください。

インデックスマージの最適化を使用するクエリは、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';   

この場合、検索エンジンは両方のインデックスを検索します。ただし、バグが原因で、マージされた結果は正しくありません。

この問題を解決するには、次のいずれかを実行します。

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

バージョン 5.6.4 以前のバージョンを実行する DB インスタンスがある場合や、DB インスタンスをバージョン 5.6.4 よりも前のバージョンからアップグレードした場合、MySQL バージョン 5.6.21 を実行するリードレプリカがあると、次のエラーが出力されることがあります。

mysqld got signal 11 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
We will try our best to scrape up some info that will hopefully help
diagnose the problem, but since we have already crashed,
something is definitely wrong and this may fail.  

MySQL バージョン 5.6.4 では、datetime、time、timestamp 列で、日付と時刻の値に小数部を使用できる新しい日付と時刻の形式が導入されました。このエラーはマスターとレプリカの間で日付と時刻の形式が一致していないことが原因で発生します。その結果、行ベースのログ作成で、マスター DB インスタンスからレプリカ DB インスタンスに、オペレーションを再現しようとすると失敗します。また、MySQL エラーログに多くの関連する行ベースのログ作成メッセージが表示されることもあります（Relay_log_info、Rows_log_event など）。MySQL の新しい日付と時刻の形式については、MySQL のドキュメントの「MySQL 5.5 から MySQL 5.6 にアップグレードする」を参照してください。

エラーを解決するには、次のいずれかを実行します。

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

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

Amazon RDS MySQL DB インスタンスの場合、InnoDB file-per-table テーブル領域を使用するとき、プロビジョンドストレージの最大サイズにより、テーブルのサイズは最大 6 TB に制限されます。また、システムのテーブルスペースも最大 6 TB に制限されています。テーブルがそれぞれに固有のテーブル領域に存在する InnoDB file-per-table テーブル領域は、Amazon RDS MySQL 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 テーブルスペースを有効または無効にすると、次の例のように ALTER TABLE コマンドを実行してテーブルをグローバルテーブルスペースから固有のテーブルスペースに、または固有のテーブルスペースからグローバルテーブルスペースに移動できます。

ALTER TABLE table_name ENGINE=InnoDB;