メニュー
Amazon Relational Database Service
ユーザーガイド (API Version 2014-10-31)

Amazon RDS での MySQL

Amazon RDS では、MySQL の複数のバージョンを実行する DB インスタンスがサポートされています。まず、Amazon RDS の管理ツールまたはインターフェイスを使用して Amazon RDS MySQL DB インスタンスを作成します。その後、DB インスタンスの再設定、DB インスタンスへの接続の許可、バックアップやスナップショットの作成やそれらからの復元、マルチ AZ セカンダリの作成、リードレプリカの作成、DB インスタンスのパフォーマンスのモニタリングが可能になります。標準的な MySQL のユーティリティとアプリケーションを使用して、DB インスタンスに対してデータを保存したりデータにアクセスしたりします。

Amazon RDS for MySQL は、多くの業界標準に準拠しています。たとえば、Amazon RDS for MySQL データベースを使用して、HIPAA 準拠のアプリケーションを構築し、AWS で実行される事業提携契約 (BAA) で保護されるべき医療情報 (PHI) を含む医療関連の情報を格納できます。Amazon RDS for MySQL は、Federal Risk and Authorization Management Program (FedRAMP) のセキュリティ要件も満たしており、AWS GovCloud (米国) リージョン内の FedRAMP HIGH ベースラインにおいて FedRAMP Joint Authorization Board (JAB) Provisional Authority to Operate (P-ATO) に認定されています。サポートされるコンプライアンス標準の詳細については、「AWS クラウドコンプライアンス」を参照してください。

以下は、Amazon RDS MySQL DB インスタンスで実行する一般的な管理タスクと、各タスクの関連資料へのリンクです。

タスク領域 関連資料

Amazon Relational Database Service (Amazon RDS) について

DB インスタンス、リージョン、アベイラビリティーゾーン、セキュリティグループ、パラメータグループ、オプショングループなど、Amazon RDS の主要コンポーネントについて理解します。

Amazon Relational Database Service (Amazon RDS) とは

新しい RDS MySQL DB インスタンスの計画

MySQL バージョンのアップグレード、ストレージエンジン、セキュリティ、および Amazon RDS でサポートされているその他の機能などを含め、新しい RDS MySQL DB インスタンスをベストプラクティスに従って計画します。

Amazon RDS での MySQL の計画についての情報

Amazon RDS を初めてセットアップして使う

Amazon RDS をセットアップして、Amazon Web Services (AWS) で MySQL DB インスタンスを作成できるようにします。

Amazon RDS のセットアップ

Amazon RDS DB インスタンスを理解する

AWS で実行する仮想 MySQL サーバーインスタンスを作成します。DB インスタンスは Amazon RDS の構成要素であるため、その原則を理解してください。

Amazon RDS DB インスタンス

本稼働用の DB インスタンスの作成

本稼働用の DB インスタンスを作成します。インスタンスの作成には、適切な処理能力とメモリ容量を備えた DB インスタンスクラスを選択することと、データベースの想定される使用方法をサポートするストレージタイプを選択することが含まれます。

DB インスタンスクラス

Amazon RDS ストレージの種類

MySQL データベースエンジンを実行する DB インスタンスの作成

DB インスタンスのセキュリティの管理

デフォルトでは、DB インスタンスが作成されると、アクセスを禁止するファイアウォールが設定されます。DB インスタンスにアクセスするために、正しい IP アドレスとネットワーク構成を備えたセキュリティグループを作成する必要があります。AWS Identity and Access Management (IAM) ポリシーを使用してアクセス権限を割り当てることで、RDS リソースの管理を許可するユーザーを指定することもできます。

Amazon RDS でのセキュリティ

Amazon RDS リソースへのアクセス権限の管理の概要

Amazon RDS セキュリティグループ

EC2-VPC または EC2-Classic のどちらのプラットフォームを使用するか判断する

DB インスタンスへの接続

MySQL コマンドラインユーティリティや MySQL Workbench などの標準の SQL クライアントアプリケーションを使用して DB インスタンスに接続します。

MySQL データベースエンジンを実行している DB インスタンスに接続する

本稼働 DB インスタンスの高可用性の設定

別のアベイラビリティーゾーンにおけるスタンバイの同期レプリケーション、自動フェイルオーバー、耐障害性、マルチ AZ 配置を使用する DB インスタンス、およびリードレプリカでの高可用性を提供します。

高可用性 (マルチ AZ)

Amazon Virtual Private Cloud での DB インスタンスの設定

Amazon VPC サービスで Virtual Private Cloud (VPC) を設定します。Amazon VPC は、AWS の他の仮想ネットワークから論理的に隔離された仮想ネットワークです。

EC2-VPC または EC2-Classic のどちらのプラットフォームを使用するか判断する

VPC 内の Amazon RDS DB インスタンスの使用

MySQL データベースの特定のパラメーターと機能の設定

多数の DB インスタンスと関連付けることができるパラメータグループを使用して MySQL データベースの特定のパラメーターを設定します。また、多数の DB インスタンスと関連付けることができるオプショングループを使用して MySQL データベースの特定の機能を設定することもできます。

DB パラメータグループを使用する

オプショングループを使用する

付録: MySQL データベースエンジンのオプション

MySQL データベースエンジンを実行する DB インスタンスの変更

ストレージの追加や DB インスタンスクラスの変更などのタスクを完了するために、DB インスタンスの設定を変更します。

MySQL データベースエンジンを実行する DB インスタンスの変更

Amazon RDS DB インスタンスを変更し、Apply Immediately パラメーターを使用する

データベースのバックアップと復元の設定

DB インスタンスを設定して自動バックアップを作成します。完全バックアップファイルを使用して、データベースを手動でバックアップおよび復元することもできます。

バックアップの使用

Amazon RDS DB インスタンスのバックアップと復元

データのインポートとエクスポート

他の RDS MySQL DB インスタンス、Amazon RDS の外部で動作する MySQL インスタンス、およびその他の種類のデータソースからデータをインポートし、Amazon RDS の外部で動作する MySQL インスタンスにデータをエクスポートします。

MySQL DB インスタンスからのデータのインポートおよびエクスポート

MySQL DB インスタンスのモニタリング

Amazon CloudWatch RDS メトリクス、イベント、および拡張モニタリングを使用して、RDS MySQL DB インスタンスをモニタリングします。RDS MySQL DB インスタンスのログファイルを確認します。

Amazon RDS のモニタリング

DB インスタンスのメトリクスの表示

Amazon RDS のイベントの表示

Amazon RDS データベースログファイル

MySQL データベースログファイル

データのレプリケーション

ロードバランシング、災害対策、読み取りの多いデータベースワークロードの処理 (分析や報告などの目的) のために MySQL リードレプリカを (オプションとして、別の AWS リージョンで) 作成します。

PostgreSQL、MySQL、および MariaDB リードレプリカの使用

Amazon RDS の外部で実行される MySQL または MariaDB インスタンスとのレプリケーション

さらに、Amazon RDS MySQL DB インスタンスの使用に役立つ情報を以下の付録で提供しています。

Amazon RDS での MySQL の計画についての情報

Amazon RDS での MySQL のバージョン

MySQL のバージョン番号は、バージョン = X.Y.Z として編成されています。Amazon RDS の用語では、X.Y はメジャーバージョン番号、Z はマイナーバージョン番号を示します。Amazon RDS 実装では、メジャーバージョン番号が変更された場合 (5.6 から 5.7 へなど)、そのバージョン変更はメジャーと考えます。マイナーバージョン番号のみが変更された場合 (5.6.22 から 5.6.23 へなど)、そのバージョン変更はマイナーと考えます。

Amazon RDS では現在、MySQL のメジャーバージョン 5.5、5.6、5.7 がサポートされています。MySQL のマイナーバージョンのサポートは、AWS リージョンによって異なります。各 AWS リージョンでサポートされている MySQL マイナーバージョンについては、次の表を参照してください。

AWS リージョン サポートされている MySQL 5.5 のマイナーバージョン サポートされている MySQL 5.6 のマイナーバージョン サポートされている MySQL 5.7 のマイナーバージョン
米国東部 (バージニア北部) リージョン (us-east-1) 5.5.46、5.5.53 5.6.19a、5.6.19b、5.6.21、5.6.21b、5.6.22、5.6.23、5.6.27、5.6.29、5.6.34 5.7.10、5.7.11、5.7.16
米国東部(オハイオ)リージョン (us-east-2) 5.5.46、5.5.53 5.6.29、5.6.34 5.7.11、5.7.16
米国西部 (北カリフォルニア) リージョン (us-west-1) 5.5.46、5.5.53 5.6.19a、5.6.19b、5.6.21、5.6.21b、5.6.22、5.6.23、5.6.27、5.6.29、5.6.34 5.7.10、5.7.11、5.7.16
米国西部 (オレゴン) リージョン (us-west-2) 5.5.46、5.5.53 5.6.19a、5.6.19b、5.6.21、5.6.21b、5.6.22、5.6.23、5.6.27、5.6.29、5.6.34 5.7.10、5.7.11、5.7.16
アジアパシフィック (ムンバイ) リージョン (ap-south-1) 5.5.46、5.5.53 5.6.27、5.6.29、5.6.34 5.7.10、5.7.11、5.7.16
アジアパシフィック (ソウル) リージョン (ap-northeast-2) 5.5.46、5.5.53 5.6.23、5.6.27、5.6.29、5.6.34 5.7.10、5.7.11、5.7.16
アジアパシフィック (シンガポール) リージョン (ap-southeast-1) 5.5.46、5.5.53 5.6.19a、5.6.19b、5.6.21、5.6.21b、5.6.22、5.6.23、5.6.27、5.6.29、5.6.34 5.7.10、5.7.11、5.7.16
アジアパシフィック (シドニー) リージョン (ap-southeast-2) 5.5.46、5.5.53 5.6.19a、5.6.19b、5.6.21、5.6.21b、5.6.22、5.6.23、5.6.27、5.6.29、5.6.34 5.7.10、5.7.11、5.7.16
アジアパシフィック (東京) リージョン (ap-northeast-1) 5.5.46、5.5.53 5.6.19a、5.6.19b、5.6.21、5.6.21b、5.6.22、5.6.23、5.6.27、5.6.29、5.6.34 5.7.10、5.7.11、5.7.16
カナダ (中部) リージョン (ca-central-1) 5.5.46、5.5.53 5.6.29、5.6.34 5.7.11、5.7.16
欧州 (フランクフルト) リージョン (eu-central-1) 5.5.46、5.5.53 5.6.19a、5.6.19b、5.6.21、5.6.21b、5.6.22、5.6.23、5.6.27、5.6.29、5.6.34 5.7.10、5.7.11、5.7.16
欧州 (アイルランド) リージョン (eu-west-1) 5.5.46、5.5.53 5.6.19a、5.6.19b、5.6.21、5.6.21b、5.6.22、5.6.23、5.6.27、5.6.29、5.6.34 5.7.10、5.7.11、5.7.16
欧州 (ロンドン) リージョン (eu-west-2) 5.5.46、5.5.53 5.6.29、5.6.34 5.7.11、5.7.16
南米 (サンパウロ) リージョン (sa-east-1) 5.5.46、5.5.53 5.6.19a、5.6.19b、5.6.21、5.6.21b、5.6.22、5.6.23、5.6.27、5.6.29、5.6.34 5.7.10、5.7.11、5.7.16

今後、Amazon RDS でサポートされる MySQL バージョンの追加も予定されています。毎年サポートされる新しいバージョンリリースの数は、MySQL バージョンリリースの頻度とコンテンツ、および当社のデータベース技術チームのリリース診断結果により異なります。ただし、一般的なガイダンスとして、当社では、一般公開リリースの 3〜5 か月以内に新しい MySQL バージョンをサポートできるよう取り組んでいます。

新しい DB インスタンスを作成するときは、現在サポートされているいずれかの MySQL バージョンを指定できます。MySQL 5.7、5.6、または 5.5 のメジャーバージョンと共に、指定したメジャーバージョンのいずれかのサポートされているマイナーバージョンを指定できます。バージョンを指定しない場合、Amazon RDS では、サポートされているいずれかのバージョン、通常はデフォルトで最新のバージョンに設定されます。マイナーバージョンではなく、メジャーバージョン (MySQL 5.7 など) を指定した場合、Amazon RDS は、お客様が指定したメジャーバージョンの最新リリースをデフォルトに設定します。サポートされているバージョンの一覧と新しく作成される DB インスタンスのデフォルトを見るには、DescribeDBEngineVersions API アクションを使います。

Amazon RDS を使用して、Amazon RDS でサポートされている新しいバージョンに MySQL インスタンスをアップグレードするタイミングを制御します。特定の MySQL バージョンとの互換性を維持しながら、新しいバージョンを本稼働環境へのデプロイ前にアプリケーションに対してテストし、自分のスケジュールに最適なタイミングでバージョンアップグレードを実行できます。

お客様が指定しない限り、お客様の DB インスタンスは、新しい MySQL マイナーバージョン (Amazon RDS がサポートするバージョン) に自動的にアップグレードされます。このパッチの適用は、スケジュールされたメンテナンス時間中に行われ、事前に Amazon RDS コミュニティフォーラムで告知されます。自動バージョンアップグレードをオフにするには、AutoMinorVersionUpgrade パラメーターを「false」に設定します。

スケジュールされた自動アップグレードを解除している場合は、サポートされているマイナーバージョンリリースに手動でアップグレードできます。その手順はメジャーバージョンの更新の場合と同じです。詳細については、DB インスタンスと DB クラスターのメンテナンスとアップグレード を参照してください。

Amazon RDS では、現在、MySQL バージョン 5.5 からバージョン 5.6 へ、MySQL バージョン 5.6 からバージョン 5.7 へのメジャーバージョンアップグレードがサポートされています。メジャーバージョンアップグレードは、何らかの互換性のリスクを伴うため、自動的には行われません。DB インスタンスを変更するリクエストを行う必要があります。本稼働インスタンスのアップグレード前に、どのアップグレードも完全にテストする必要があります。DB インスタンスのアップグレードについては、「DB インスタンスと DB クラスターのメンテナンスとアップグレード」を参照してください。

DB インスタンスを新しいバージョンに対してテストできます。そのためには、既存の DB インスタンスの DB スナップショットを作成し、DB スナップショットから復元して新しい DB インスタンスを作成した後、その新しい DB インスタンスのバージョンアップグレードを開始します。その後で、オリジナルの DB インスタンスをアップグレードするかどうかを決める前に、コピーした DB インスタンスで安全性を確かめることができます。

以下に、Amazon RDS MySQL の廃止についてのポリシーを示します。

  • 当社ではメジャー MySQL バージョンリリース (MySQL 5.5 を含む) に対して、Amazon RDS によるサポートが開始されてから 3 年間のサポートを予定しています。

  • マイナー MySQL バージョンリリース (MySQL 5.5.46 など) に対しては、Amazon RDS によるサポートが開始されてから、少なくとも 1 年間のサポートを予定しています。

  • MySQL メジャー/マイナーバージョンが「廃止」となった後は、予定メンテナンスで自動アップグレードされる前に、ユーザーがサポート対象バージョンにアップグレードするための猶予期間を 3 か月間設けます。

MySQL の memcached オプションを使用する

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

Amazon RDS でサポートされているストレージエンジン

MySQL ではさまざまな機能を備えた複数のストレージエンジンがサポートされていますが、それらのすべてのエンジンが回復性やデータ耐久性のために最適化されているわけではありません。Amazon RDS では、MySQL DB インスタンス用に InnoDB ストレージエンジンが完全にサポートされています。Amazon RDS のポイントインタイム復元やスナップショット復元などの機能では、回復可能なストレージエンジンが必要であるため、InnoDB ストレージエンジンのみがサポートされています。InnoDB memcached インターフェイスを使用するには、MySQL 5.6 以降のインスタンスを実行している必要があります。詳細については、「MySQL の memcached サポート」を参照してください。

Federated ストレージエンジンは、現在、Amazon RDS MySQL ではサポートされていません。

MyISAM ストレージエンジンでは、信頼性の高い回復がサポートされておらず、エンジンの回復後に MySQL が再起動したとき、ポイントインタイム復元またはスナップショット復元が意図したとおりに機能せず、データが紛失または破損する場合があります。それでも Amazon RDS で MyISAM を使用する場合は、スナップショットがいくつかの条件下で役立つことがあります。

既存の MyISAM テーブルを InnoDB テーブルに変換するには、alter table コマンドを使用します (たとえば、alter table TABLE_NAME engine=innodb;)。MyISAM と InnoDB の長所と短所は異なっているため、アプリケーションで切り替えた際の影響を切り替え前に十分に評価しておく必要があることを念頭に置いてください。

MySQL 5.1 は、Amazon RDS のサポート対象外になりました。ただし、既存の MySQL 5.1 スナップショットは復元できます。MySQL 5.1 スナップショットを復元すると、インスタンスが MySQL 5.5 に自動的にアップグレードされます。

Amazon RDS と MySQL のセキュリティ

Amazon RDS MySQL DB インスタンスのセキュリティは以下の 3 つのレベルで管理されます。

  • AWS Identity and Access Management では、どのユーザーが DB インスタンスに対して Amazon RDS の管理アクションを実行できるかを制御します。IAM 認証情報を使用して AWS に接続するとき、IAM アカウントには、Amazon RDS の管理オペレーションを実行するためのアクセス許可を付与する IAM ポリシーが必要です。詳細については、「Amazon RDS に対する認証とアクセスコントロール」を参照してください。

  • DB インスタンスを作成するときは、VPC セキュリティグループまたは DB セキュリティグループのいずれかを使用して、どのデバイスまたは Amazon EC2 インスタンスが DB インスタンスのエンドポイントとポートへの接続を開くことができるかを制御します。これらの接続に SSL の使用を求めることもできます。さらに、会社のファイアウォールルールでも、社内のどのデバイスが DB インスタンスへの接続を開くことができるかを制御できます。

  • MySQL DB インスタンスに対するログインとアクセス権限を認証するには、次の方法のいずれか、または組み合わせて行います。

    MySQL のスタンドアロンインスタンスと同じ方法を使用することもできます。CREATE USERRENAME USERGRANTREVOKESET PASSWORD などのコマンドは、オンプレミスデータベースでの方法と同様に、データベーススキーマテーブルを直接変更します。詳細については、MySQL のドキュメントの「MySQL ユーザーアカウントの管理」を参照してください。

    IAM データベース認証を使用することもできます。IAM データベース認証を使用する場合は、IAM ユーザーまたは IAM ロールおよび認証トークンを使用して、DB インスタンスを認証します。認証トークン は、署名バージョン 4 の署名プロセスを使用して生成されている一意の値です。IAM データベース認証では、同一の認証情報を使用して AWS リソースおよびデータベースへのアクセスを制御できます。詳細については、「MySQL および Amazon Aurora に対する IAM データベース認証」を参照してください。

Amazon RDS DB インスタンスを作成すると、マスターユーザーには以下のデフォルト権限が付与されます。

  • alter

  • alter routine

  • create

  • create routine

  • create temporary tables

  • create user

  • create view

  • delete

  • drop

  • event

  • execute

  • grant option

  • index

  • insert

  • lock tables

  • process

  • references

  • replication client

  • replication slave (MySQL 5.6 and later)

  • select

  • show databases

  • show view

  • trigger

  • update

注記

DB インスタンスのマスターユーザーを削除できますが、お勧めしません。マスターユーザーを再作成するには、RDS API の ModifyDBInstance アクション、または AWS CLI の modify-db-instance ツールを使用して、新しいマスターユーザーのパスワードを該当するパラメーターで指定します。インスタンスに既存のマスターユーザーがない場合、指定したパスワードを使用してマスターユーザーが作成されます。

各 DB インスタンスに管理サービスを提供するために、DB インスタンスの作成時に rdsadmin ユーザーが作成されます。rdsadmin アカウントの権限をドロップ、名前変更、パスワード変更、または変更しようとするとエラーになります。

DB インスタンスの管理を可能にするために、標準的なコマンド killkill_query の使用は制限されています。代わりに、Amazon RDS のコマンド rds_killrds_kill_query が用意されており、DB インスタンスでのユーザーセッションやクエリを終了させるために使用できます。

MySQL DB インスタンスで SSL を使用する

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

注記

Amazon Aurora は MySQL と互換性があります。ただし、Amazon Aurora DB クラスターへの接続には別の SSL 証明書を使用します。SSL を使用して Amazon Aurora に接続する方法については、「SSL での Aurora データの保護」を参照してください。

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 を使用して AWS GovCloud (米国) リージョンに接続するために、中間証明書を使用する必要があります。 ダウンロードできるリージョンの中間証明書のリストについては、「中間証明書」を参照してください。

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

Copy
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 接続を求めることができます。

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

注記

MySQL での SSL 接続の詳細については、MySQL のドキュメントを参照してください。

MySQL DB インスタンスのローカルタイムゾーン

デフォルトでは、RDS MySQL DB インスタンスのタイムゾーンは協定世界時 (UTC) です。代わりに、DB インスタンスのタイムゾーンをアプリケーションのローカルタイムゾーンに設定できます。

DB インスタンスのローカルタイムゾーンを設定するには、DB インスタンスのパラメータグループの time_zone パラメーターを、このセクションで後述するサポートされている値のいずれかに設定します。パラメータグループの time_zone パラメーターを設定すると、そのパラメータグループを使用しているすべての DB インスタンスとリードレプリカは、新しいローカルタイムゾーンを使用するように変更されます。パラメータグループのパラメーターの設定については、「DB パラメータグループを使用する」を参照してください。

ローカルタイムゾーンを設定した後、データベースへのすべての新しい接続にその変更が反映されます。ローカルタイムゾーンを変更するときにデータベースへの接続を開いている場合、その接続を閉じて新しい接続を開くまで、ローカルタイムゾーンは更新されません。

DB インスタンスとそのリードレプリカには異なるローカルタイムゾーンを設定できます。そのためには、DB インスタンスとレプリカに異なるパラメータグループを使用し、各パラメータグループの time_zone パラメーターを異なるローカルタイムゾーンに設定します。

リージョン間のレプリケーションを実行する場合は、レプリケーションマスター DB インスタンスとリードレプリカに異なるパラメータグループ (パラメータグループはリージョンに固有のもの) を使用します。各インスタンスに同じローカルタイムゾーンを使用するには、インスタンスとリードレプリカのパラメータグループの time_zone パラメーターを設定する必要があります。

DB スナップショットから DB インスタンスを復元すると、ローカルタイムゾーンが UTC に設定されます。復元が完了したら、タイムゾーンをローカルタイムゾーンに更新できます。DB インスタンスをある時点まで復元する場合、復元された DB インスタンスのローカルタイムゾーンは、復元された DB インスタンスのパラメータグループに設定されているタイムゾーンです。

ローカルタイムゾーンは MySQL バージョン 5.5、5.6、5.7 でのみサポートされています。

ローカルタイムゾーンは以下のいずれかの値に設定できます。

Africa/Cairo

Asia/Bangkok

Australia/Darwin

Africa/Casablanca

Asia/Beirut

Australia/Hobart

Africa/Harare

Asia/Calcutta

Australia/Perth

Africa/Monrovia

Asia/Damascus

Australia/Sydney

Africa/Nairobi

Asia/Dhaka

Brazil/East

Africa/Tripoli

Asia/Irkutsk

Canada/Newfoundland

Africa/Windhoek

Asia/Jerusalem

Canada/Saskatchewan

America/Araguaina

Asia/Kabul

Europe/Amsterdam

America/Asuncion

Asia/Karachi

Europe/Athens

America/Bogota

Asia/Kathmandu

Europe/Dublin

America/Caracas

Asia/Krasnoyarsk

Europe/Helsinki

America/Chihuahua

Asia/Magadan

Europe/Istanbul

America/Cuiaba

Asia/Muscat

Europe/Kaliningrad

America/Denver

Asia/Novosibirsk

Europe/Moscow

America/Fortaleza

Asia/Riyadh

Europe/Paris

America/Guatemala

Asia/Seoul

Europe/Prague

America/Halifax

Asia/Shanghai

Europe/Sarajevo

America/Manaus

Asia/Singapore

Pacific/Auckland

America/Matamoros

Asia/Taipei

Pacific/Fiji

America/Monterrey

Asia/Tehran

Pacific/Guam

America/Montevideo

Asia/Tokyo

Pacific/Honolulu

America/Phoenix

Asia/Ulaanbaatar

Pacific/Samoa

America/Santiago

Asia/Vladivostok

US/Alaska

America/Tijuana

Asia/Yakutsk

US/Central

Asia/Amman

Asia/Yerevan

US/Eastern

Asia/Ashgabat

Atlantic/Azores

US/East-Indiana

Asia/Baghdad

Australia/Adelaide

US/Pacific

Asia/Baku

Australia/Brisbane

UTC

InnoDB キャッシュウォームアップ

InnoDB キャッシュウォームアップでは、DB インスタンスがシャットダウンされたときのバッファープールの最新の状態を保存し、DB インスタンスが起動されたときに保存された情報からバッファープールを再ロードすることによって、MySQL DB インスタンスのパフォーマンスを向上させることができます。これにより、通常のデータベースの使用からバッファープールを「ウォームアップする」必要がなくなり、既知の一般的なクエリのページを使用してバッファープールを事前にロードします。保存されたバッファープール情報を格納するファイルには、バッファープールのページ自体ではなく、バッファープール内のページのメタデータのみが格納されます。そのため、このファイルは多くのストレージ領域を必要としません。ファイルサイズは、キャッシュサイズの約 0.2% となります。たとえば、64 GB のキャッシュでは、キャッシュのウォームアップファイルのサイズは 128 MB です。InnoDB キャッシュウォームアップの詳細については、MySQL のドキュメントの「バッファプールの状態のダンプと復元」を参照してください。

Amazon RDS での MySQL は、MySQL バージョン 5.6 以降の InnoDB キャッシュウォームアップをサポートします。InnoDB キャッシュウォームアップを有効にするには、DB インスタンスのパラメータグループで innodb_buffer_pool_dump_at_shutdown および innodb_buffer_pool_load_at_startup パラメーターを 1 に設定します。パラメータグループのこれらのパラメーター値を変更すると、パラメータグループを使用するすべての MySQL DB インスタンスに影響します。特定の MySQL DB インスタンスの InnoDB キャッシュウォームアップを有効にするには、それらのインスタンスの新しいパラメータグループを作成することが必要になる場合があります。パラメータグループについては、「DB パラメータグループを使用する」を参照してください。

InnoDB キャッシュウォームアップは、主に、標準ストレージを使用している DB インスタンスにパフォーマンス上のメリットをもたらします。PIOPS ストレージを使用する場合、一般的に大きなパフォーマンス上のメリットは見られません。

重要

フェイルオーバー時など、MySQL DB インスタンスが正常にシャットダウンしなかった場合、バッファープールの状態はディスクに保存されません。この場合、DB インスタンスが再開されるときに、MySQL は利用可能な任意のバッファープールファイルをロードします。特に害はありませんが、復元されたバッファープールは、再開前のバッファープールの最新の状態を反映していない可能性があります。起動時に InnoDB キャッシュをウォームアップするために、バッファープールの最新の状態が利用できるようにするには、定期的に「オンデマンド」でバッファープールをダンプすることをお勧めします。DB インスタンスが MySQL バージョン 5.6.19 以降を実行している場合、バッファープールをオンデマンドでダンプまたはロードできます。

自動で定期的にバッファープールをダンプするイベントを作成できます。たとえば、次のステートメントは、1 時間ごとにバッファープールをダンプする periodic_buffer_pool_dump という名前のイベントを作成します。

Copy
CREATE EVENT periodic_buffer_pool_dump ON SCHEDULE EVERY 1 HOUR DO CALL mysql.rds_innodb_buffer_pool_dump_now();
MySQL のイベントの詳細については、MySQL のドキュメントの「イベントの構文」を参照してください。

オンデマンドでのバッファプールのダンプとロード

MySQL バージョン 5.6.19 以降の場合、InnoDB キャッシュを「オンデマンド」で保存およびロードできます。

Amazon RDS でサポートされていない MySQL の機能

Amazon RDS では、現在、MySQL の以下の機能はサポートされていません。

  • グローバルトランザクション ID

  • トランスポータブルテーブルスペース

  • 認証用プラグイン

  • パスワード強度用プラグイン

  • レプリケーションフィルタ

  • 準同期レプリケーション

マネージド型サービスの操作性を実現するために、Amazon RDS では DB インスタンスへのシェルアクセスはできません。また、上位の権限を必要とする特定のシステムプロシージャやシステムテーブルへのアクセスが制限されます。Amazon RDS では、標準的な SQL クライアントアプリケーションを使用した、DB インスタンス上のデータベースへのアクセスがサポートされています。Amazon RDS では、Telnet、Secure Shell (SSH)、または Windows のリモートデスクトップ接続を使用した、DB インスタンスへのダイレクトホストアクセスは許可されません。DB インスタンスを作成すると、そのインスタンス上のすべてのデータベースに対する db_owner ロールに割り当てられ、すべてのデータベースレベルのアクセス許可が付与されます (バックアップのためのアクセス許可は付与されません。バックアップは Amazon RDS によって管理されます)。

既知の問題と制限

既知の問題および制限は次のとおりです。

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

Copy
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 のバージョン

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

MySQL バージョン 5.5.40 の非同期 I/O が無効である

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=72745http://bugs.mysql.com/bug.php?id=68194 を参照してください。

たとえば、2 つのインデックスを持つテーブルで、検索引数がインデックス付き列を参照するクエリがあるとします。

Copy
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.19a にアップグレードします。メジャーバージョンのアップグレードについては、「DB インスタンスと DB クラスターのメンテナンスとアップグレード」を参照してください。

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

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

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

MySQL Version 5.6.21 にアップグレードした後、レプリケーションに失敗する

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

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

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

  • リードレプリカを MySQL バージョン 5.6.23 以降にアップグレードします。Amazon RDS 上の MySQL DB インスタンスをバージョン 5.6 にアップグレードする方法については、「データベースエンジンバージョンのアップグレード」を参照してください。

  • マスター DB インスタンスを MySQL バージョン 5.6.12 以降にアップグレードし、影響を受ける日付と時刻の列の形式を更新します。Amazon RDS 上の MySQL DB インスタンスをバージョン 5.6 にアップグレードする方法については、「データベースエンジンバージョンのアップグレード」を参照してください。

    マスター DB インスタンスで日付と時刻の列を新しい形式にアップグレードするには、ALTER TABLE <table_name> FORCE; コマンドを発行する必要があります。

    注記

    テーブルを変更すると、テーブルが読み取り専用としてロックされるため、この更新はメンテナンス時間中に実行することをお勧めします。

    次のクエリを実行して、データベース内で datetimetime、または timestamp 型の列を含むテーブルをすべて検索し、各テーブルについて ALTER TABLE <table_name> FORCE; コマンドを作成できます。

    Copy
    SELECT DISTINCT CONCAT('ALTER TABLE `', REPLACE(is_tables.TABLE_SCHEMA, '`', '``'), '`.`', REPLACE(is_tables.TABLE_NAME, '`', '``'), '` FORCE;') FROM information_schema.TABLES is_tables INNER JOIN information_schema.COLUMNS col ON col.TABLE_SCHEMA = is_tables.TABLE_SCHEMA AND col.TABLE_NAME = is_tables.TABLE_NAME LEFT OUTER JOIN information_schema.INNODB_SYS_TABLES systables ON SUBSTRING_INDEX(systables.NAME, '#', 1) = CONCAT(is_tables.TABLE_SCHEMA,'/',is_tables.TABLE_NAME) LEFT OUTER JOIN information_schema.INNODB_SYS_COLUMNS syscolumns ON syscolumns.TABLE_ID = systables.TABLE_ID AND syscolumns.NAME = col.COLUMN_NAME WHERE col.COLUMN_TYPE IN ('time','timestamp','datetime') AND is_tables.TABLE_TYPE = 'BASE TABLE' AND is_tables.TABLE_SCHEMA NOT IN ('mysql','information_schema','performance_schema') AND (is_tables.ENGINE = 'InnoDB' AND syscolumns.MTYPE = 6);

ログファイルのサイズ

MySQL バージョン 5.6.20 以降では、redo ログに書き込まれる BLOB にサイズ制限があります。この制限に対処するには、MySQL DB インスタンスの innodb_log_file_size パラメーターを、テーブル内で最も大きい BLOB データサイズに、同テーブル内の他の可変長フィールド (VARCHARVARBINARYTEXT) を足した長さより 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 インスタンスで不整合が生じることがあるためです。

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

long_query_time

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

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

Amazon RDS MySQL DB インスタンスの場合、InnoDB file-per-table テーブル領域を使用するとき、プロビジョンドストレージの最大サイズにより、テーブルのサイズは最大 6 TB に制限されます。また、システムのテーブルスペースも最大 6 TB に制限されています。テーブルがそれぞれに固有のテーブル領域に存在する InnoDB file-per-table テーブル領域は、Amazon RDS MySQL 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 コマンドを使用して、パーティション化の対象になる過度に大きなテーブルがあるか判断します。

Copy
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 コマンドを実行してテーブルをグローバルテーブルスペースから固有のテーブルスペースに、または固有のテーブルスペースからグローバルテーブルスペースに移動できます。

Copy
ALTER TABLE table_name ENGINE=InnoDB;

このページの内容: