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

Amazon Aurora の概要

Amazon Aurora (Aurora) は、フルマネージド型の MySQL と互換性のあるリレーショナルデータベースエンジンであり、ハイエンドな商用データベースのスピードと信頼性、オープンソースデータベースの簡素性とコスト効率性を兼ね備えています。既存のアプリケーションをほとんど変更せずに、MySQL に比べ、最大 5 倍のパフォーマンスを実現します。

Amazon Aurora では新しい MySQL や既存の MySQL のデプロイの設定、操作、およびのスケーリングを簡単かつコスト効率良く実行できるため、業務やアプリケーションに労力を向けることができます。Amazon Relational Database Service (Amazon RDS) では、データベースのプロビジョニング、パッチ適用、バックアップ、復旧、障害検出、修復などのルーチンタスクを処理することで Amazon Aurora を管理します。Amazon RDS には、MySQL アプリケーション用の既存の Amazon RDS を Amazon Aurora に変換するための押しボタン式の移行ツールも用意されています。

Amazon Aurora は、MySQL のドロップインリプレースメントです。既存の MySQL データベースで現在使用しているコード、ツール、アプリケーションを Amazon Aurora でも使用できます。

Amazon Aurora インスタンスを作成すると、DB クラスターが作成されます。DB クラスターは、1 つ以上のインスタンスと、これらのインスタンスのデータを管理する 1 つのクラスターボリュームで構成されます。Aurora クラスターボリュームは、複数のアベイラビリティーゾーンにまたがる仮想データベースストレージボリュームです。各アベイラビリティーゾーンにはクラスターデータのコピーが格納されます。Aurora DB クラスターは 2 種類のインスタンスで構成されます。

  • プライマリインスタンス – 読み取り/書き込みワークロードをサポートし、クラスターボリュームに対するすべてのデータ変更を実行します。各 Aurora DB クラスターには 1 つのプライマリインスタンスがあります。

  • Aurora レプリカ – 読み取りオペレーションのみをサポートします。各 DB クラスターは、読み取り/書き込みワークロードをサポートするプライマリインスタンスに加え、最大 15 個の Aurora レプリカを持つことができます。複数の Aurora レプリカは読み取りワークロードを分散し、別のアベイラビリティーゾーンの Aurora レプリカを検索することでデータベースの可用性を高めることもできます。

次の図は、Aurora DB クラスター内の Amazon Aurora クラスターボリューム、プライマリインスタンス、および Aurora レプリカの関係を示しています。

 Amazon Aurora アーキテクチャ

現在利用できるリージョン

次の表に、Amazon Aurora を現在利用できるリージョンを示します。

サービス対象 コンソールリンク
米国東部(バージニア北部) https://console.aws.amazon.com/rds/home?region=us-east-1
米国東部 (オハイオ) https://console.aws.amazon.com/rds/home?region=us-east-2
米国西部 (北カリフォルニア) https://console.aws.amazon.com/rds/home?region=us-west-1
米国西部 (オレゴン) https://console.aws.amazon.com/rds/home?region=us-west-2
アジアパシフィック (東京) https://console.aws.amazon.com/rds/home?region=ap-northeast-1
アジアパシフィック (ムンバイ) https://console.aws.amazon.com/rds/home?region=ap-south-1
アジアパシフィック (シドニー) https://console.aws.amazon.com/rds/home?region=ap-southeast-2
アジアパシフィック (ソウル) https://console.aws.amazon.com/rds/home?region=ap-northeast-2
カナダ (中部) https://console.aws.amazon.com/rds/home?region=ca-central-1
欧州 (アイルランド) https://console.aws.amazon.com/rds/home?region=eu-west-1
欧州 (ロンドン) https://console.aws.amazon.com/rds/home?region=eu-west-2

Aurora エンドポイント

DB クラスターの複数のエンドポイントの 1 つを使用して、Aurora DB クラスター内のインスタンスに接続できます。エンドポイントは、コロンで区切られたドメイン名とポートで構成されます (例: mydbcluster.cluster-123456789012.us-east-1.rds.amazonaws.com:3306)。以下からシナリオの最適なエンドポイントを選択します。

クラスターエンドポイント

各 Aurora DB クラスターには、ユーザーが接続できるクラスターエンドポイントがあります。クラスターエンドポイントは DB クラスターのプライマリインスタンスに接続します。このクラスターエンドポイントを使用して、読み取りと書き込みの両方のオペレーションを実行できます。

プライマリインスタンスにも、それ自体の一意のエンドポイントがあります。この 2 つのエンドポイントの違いは、クラスターエンドポイントは常に現行のプライマリインスタンスをポイントすることです。つまり、プライマリインスタンスが失敗すると、クラスターエンドポイントは新しいプライマリインスタンスをポイントします。プライマリインスタンスが失敗した場合は、接続を再確立する必要があります。フェイルオーバーの詳細については、「Aurora DB クラスターの耐障害性」を参照してください。

可用性の高いシナリオでは、クラスターエンドポイントに接続することをお勧めします。こうすることで、フェイルオーバーが完了するとアプリケーションは新しいプライマリインスタンスに再接続します。フェイルオーバー中、Aurora は障害の起きたインスタンスに代わって新しく昇格したプライマリインスタンスからクラスターエンドポイントへのリクエストを処理し続けます。Aurora は最小限のサービス中断でクラスターエンドポイントに送信します。

クラスターエンドポイントの使用例として、2 つの Aurora レプリカがプライマリインスタンスとは異なるアベイラビリティーゾーンにある Aurora DB クラスターについて考えてみます。クラスターエンドポイントに接続することで、プライマリインスタンスに読み取りと書き込み両方のトラフィックを送信できます。各 Aurora レプリカのエンドポイントに接続して、それらの DB インスタンスに直接クエリを送信することもできます。プライマリインスタンス、またはプライマリインスタンスを含むアベイラビリティーゾーンで障害が発生した場合、RDS はいずれかの Aurora レプリカを新しいプライマリインスタンスに昇格させ、新しいプライマリインスタンスをポイントするようにクラスターエンドポイントのドメインネームサービス (DNS) レコードを更新します。アプリケーションは、このクラスターエンドポイントを使用して、サービスの中断を最小限に抑えた状態で、Aurora DB クラスターに対する読み取り/書き込みトラフィックを続行します。

読み込みエンドポイント

各 Aurora DB クラスターには読み込みエンドポイントがあり、これを使用して DB クラスターの Aurora レプリカの 1 つに接続できます。DB クラスターの読み込みエンドポイントは、DB クラスター内で使用できる Aurora レプリカ間で接続を負荷分散します。クライアントが読み込みエンドポイントへの新規接続をリクエストすると、Aurora によって接続リクエストが DB クラスターの Aurora レプリカ間で配分されます。この機能は、DB クラスターの複数の Aurora レプリカ間の読み取りワークロードを分散させる役に立ちます。

フェイルオーバーが発生し、接続している Aurora レプリカがプライマリインスタンスに昇格すると、接続は削除されます。読み取りワークロードをクラスター内の他の Aurora レプリカに送信し続けるには、読み込みエンドポイントに再接続します。フェイルオーバーの詳細については、「Aurora DB クラスターの耐障害性」を参照してください。

読み込みエンドポイントを使用して、DB クラスターからの読み取り専用クエリに高可用性を提供できます。このアプローチをとるには、異なるアベイラビリティーゾーンに複数の Aurora レプリカを配置してから、読み込みエンドポイントに接続して読み取りワークロードを実行します。稀にアベイラビリティーゾーンに障害が発生した場合、アプリケーションは読み込みエンドポイントを使用して、サービス中断を最小限にして DB クラスターの Aurora レプリカに読み取りトラフィックを送信し続けます。

読み込みエンドポイントは DB クラスターにある Aurora レプリカへの接続のみを負荷分散します。クエリを負荷分散してクラスターの読み取りワークロードを配分する場合は、アプリケーションでそれを管理する必要があります。

フェイルオーバー中、Aurora レプリカがプライマリインスタンスに昇格した場合に、読み込みエンドポイントが DB クラスターのプライマリインスタンスに短時間直接接続する場合があります。

クライアントが DNS 情報をキャッシュしている場合、クライアントがキャッシュされた接続設定を使用同じ Aurora レプリカに接続すると、接続の負荷分散に何らかの不一致が発生する場合があります。

インスタンスエンドポイント

DB クラスターのプライマリインスタンスと Aurora レプリカにはすべて、インスタンスエンドポイントがあります。これは、特定のインスタンスに直接接続する際に使用できる一意のエンドポイントです。インスタンスエンドポイントは、識別子に cluster- が含まれていません。たとえば、クラスターエンドポイントは mydbcluster.cluster-123456789012.us-east-1.rds.amazonaws.com:3306 であり、プライマリインスタンスのインスタンスエンドポイントは mydbcluster-primary.123456789012.us-east-1.rds.amazonaws.com:3306 です。

クライアントが Aurora DB クラスター内の複数の Aurora レプリカに接続するように構成して、アプリケーションの読み取りワークロードを分散できます。高可用性のシナリオでは、別のアベイラビリティーゾーンに Aurora レプリカを配置することもできます。別のアベイラビリティーゾーンに Aurora レプリカを配置すると、アベイラビリティーゾーンに障害が発生した場合でも、アプリケーションで Aurora DB クラスターからデータを読み込むことができます。

インスタンスエンドポイントを使用してインスタンスに接続する前に、DB クラスターのクラスターエンドポイントを使用するのか、読み込みエンドポイントを使用するのかを検討してください。DB クラスターでフェイルオーバーが発生した場合、クラスターエンドポイントを使用して新しく昇格したプライマリインスタンスに接続できます。また、読み込みエンドポイントを使用して DB クラスター内の使用可能な Aurora レプリカに接続することもできます。

Amazon Aurora ストレージ

Aurora のデータは、SSD (Solid State Disk) ドライブを利用する単一の仮想ボリュームであるクラスターボリュームに保存されます。クラスターボリュームは、単一リージョンの複数のアベイラビリティーゾーン間のデータのコピーで構成されます。データはアベイラビリティーゾーン間で自動的にレプリケートされるため、データ損失の可能性は低く、耐久性は非常に高くなります。このレプリケーションは、フェイルオーバー中のデータベースの可用性をさらに高めることも保証します。その理由は、データのコピーは既に他のアベイラビリティーゾーンに存在し、DB クラスター内のインスタンスに対するデータ要求を処理し続けるためです。

Aurora クラスターボリュームは、データベースのデータ量が増えるにつれて自動的に増加します。Aurora クラスターボリュームは、最大 64 テラバイト (TB) のサイズまで増やすことができます。テーブルサイズの上限はクラスターボリュームのサイズです。つまり、Aurora DB クラスター内のテーブルの最大テーブルサイズは 64 TB です。Aurora クラスターボリュームは 64 TB まで拡大できますが、Aurora クラスターボリュームで使用する領域に対してのみ料金が請求されます。料金表については、「Amazon RDS の Aurora 料金表」を参照してください。

Amazon Aurora レプリケーション

Aurora レプリカは Aurora DB クラスター内の独立したエンドポイントです。これらにより DB クラスターボリューム内のデータへの読み取り専用アクセスが提供され、データの読み取りのワークロードを複数のレプリケートされたインスタンスにスケーリングできるようになり、データ読み取りのパフォーマンスを向上させるとともに、Aurora DB クラスター内のデータの可用性を向上させることができます。Aurora レプリカはフェイルオーバーターゲットでもあり、Aurora DB クラスターのプライマリインスタンスに障害が発生した場合は迅速に昇格します。

Aurora レプリカおよび Aurora DB クラスターでデータをレプリケートする際に使用するその他のオプションの詳細については、「Amazon Aurora とのレプリケーション」を参照してください。

Amazon Aurora の信頼性

Aurora は、信頼性、耐久性、および耐障害性を持つように設計されています。Aurora DB クラスターは、Aurora レプリカの追加や複数のアベイラビリティーゾーンへの配置などを行うことで可用性を向上させるように設計できます。さらに Aurora には、信頼できるデータベースソリューションとして使用できるさまざまな自動機能があります。

ストレージの自動修復

Aurora では、データの複数のコピーを 3 つのアベイラビリティーゾーンに保持するため、ディスク障害によってデータが失われる機会が最小限に抑えられます。Aurora では、クラスターボリュームを構成するディスクボリュームの障害を自動的に検出します。ディスクボリュームのセグメントで障害が発生すると、Aurora はすぐにそのセグメントを修復します。Aurora はディスクセグメントを修復するときに、クラスターボリュームを構成する他のボリューム内のデータを使用して、修復されるセグメントのデータが最新であるようにします。その結果、Aurora ではデータ損失が回避され、ディスク障害から回復するためのポイントインタイム復元を実行する必要性が低減します。

"存続できる" キャッシュのウォームアップ

Aurora では、データベースがシャットダウン後に起動したとき、または障害発生後に再起動したときに、バッファプールキャッシュを "ウォームアップ" します。つまり、Aurora では、メモリ内ページキャッシュに保存された既知の一般的なクエリのページを使用してバッファープールを事前にロードします。これにより、通常のデータベースの使用からバッファープールを "ウォームアップ" する必要性をバイパスすることでパフォーマンスが向上します。

Aurora ページキャッシュはデータベースとは別のプロセスで管理されるため、ページキャッシュはデータベースとは無関係に "存続" できます。データベースに障害が発生した場合でも、ページキャッシュはメモリに残るため、バッファプールはデータベースの起動時に最新の状態にウォームアップされます。

クラッシュ回復

Aurora は、クラッシュからほぼ瞬時に回復し、アプリケーションデータを提供し続けるように設計されています。Aurora は、クラッシュの直後にデータベースを開き、使用できるようにするためにクラッシュ回復を並列スレッドで非同期に実行します。詳細については、「Aurora DB クラスターの耐障害性」を参照してください。

Aurora パフォーマンスの拡張

Amazon Aurora には、ハイエンドな商用データベースのさまざまなニーズをサポートするパフォーマンス拡張機能があります。

高速挿入

高速挿入は、プライマリキーによってソートされた並列挿入を加速し、特に LOAD DATA および INSERT INTO ... SELECT ... ステートメントに適用されます。高速挿入は、ステートメントの実行中にインデックストラバーサルのカーソル位置をキャッシュします。これによって、再度インデックスをトラバースする必要がなくなります。

次のメトリクスをモニタリングして、DB クラスターに対する高速挿入の効果を判断できます。

  • aurora_fast_insert_cache_hits: キャッシュされたカーソルが正常に取得され検証された時に増加するカウンター。

  • aurora_fast_insert_cache_misses: キャッシュされたカーソルがすでに有効ではなく、Aurora が通常のインデックストラバーサルを実行したときに増加するカウンター。

次のコマンドを使用して、高速挿入メトリクスの現在の値を取得できます。

Copy
mysql> show global status like 'Aurora_fast_insert%';

以下のような出力結果が取得できます。

Copy
+---------------------------------+-----------+ | Variable_name | Value | +---------------------------------+-----------+ | Aurora_fast_insert_cache_hits | 3598300 | | Aurora_fast_insert_cache_misses | 436401336 | +---------------------------------+-----------+

Amazon Aurora のセキュリティ

Amazon Aurora のセキュリティは次の 3 つのレベルで管理されます。

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

    IAM アカウントを使用して Amazon Aurora コンソールにアクセスする場合は、IAM アカウントで AWS マネジメントコンソール にログオンした後、https://console.aws.amazon.com/rds で Aurora プレビューコンソールに移動する必要があります。

  • Aurora DB クラスターは Amazon Virtual Private Cloud (VPC) に作成する必要があります。VPC 内の Aurora DB クラスター用の DB インスタンスのエンドポイントとポートに対して接続を開くことができるデバイスと Amazon EC2 インスタンスを制御するには、VPC セキュリティグループを使用します。これらのエンドポイントとポート接続は、Secure Sockets Layer (SSL) を使用して作成できます。さらに、会社のファイアウォールルールでも、社内のいずれのデバイスが DB インスタンスへの接続を開くことができるかを制御できます。VPC の詳細については、「Amazon Virtual Private Cloud (VPCs) と Amazon RDS」を参照してください。

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

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

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

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

  • ALTER

  • ALTER ROUTINE

  • CREATE

  • CREATE ROUTINE

  • CREATE TEMPORARY TABLES

  • CREATE USER

  • CREATE VIEW

  • DELETE

  • DROP

  • EVENT

  • EXECUTE

  • GRANT OPTION

  • INDEX

  • INSERT

  • LOAD FROM S3

  • LOCK TABLES

  • PROCESS

  • REFERENCES

  • RELOAD

  • REPLICATION CLIENT

  • REPLICATION SLAVE

  • SELECT

  • SHOW DATABASES

  • SHOW VIEW

  • TRIGGER

  • UPDATE

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

DB クラスターの管理では、標準的なコマンド killkill_query の使用は制限されています。DB インスタンスのユーザーセッションまたはクエリを終了するには、Amazon RDS の rds_kill コマンドと rds_kill_query コマンドを代わりに使用します。

SSL での Aurora データの保護

Amazon Aurora DB クラスターは、アプリケーションからの Secure Sockets Layer (SSL) 接続を、Amazon RDS MySQL DB インスタンスと同じプロセスとパブリックキーを使用してサポートします。

Amazon RDS によって、Amazon RDS インスタンスのプロビジョニング時、SSL 証明書が作成され、DB インスタンスにインストールされます。これらの証明書は認証局によって署名されます。SSL 証明書には、なりすまし攻撃から保護するために、SSL 証明書の共通名 (CN) として DB インスタンスのエンドポイントが含まれています。その結果、クライアントがサブジェクト代替名 (SAN) をサポートしている場合は、DB クラスターエンドポイントのみを使用して SSL を使用する DB クラスターに接続できます。それ以外の場合は、プライマリインスタンスのエンドポイントを使用する必要があります。ここでは、SSL で SAN をサポートするクライアントとして、MariaDB Connector/J クライアントをお勧めします。詳細については、MariaDB Connector/J のダウンロードページを参照してください。

パブリックキーは、「https://s3.amazonaws.com/rds-downloads/rds-combined-ca-bundle.pem」に保存されています。

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

mysql -h mycluster-primary.123456789012.us-east-1.rds.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 での SSL 接続の詳細については、MySQL のドキュメントを参照してください。

Amazon Aurora DB クラスターのローカルタイムゾーン

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

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

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

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

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

ローカルタイムゾーンは以下の表に示されているいずれかの値に設定できます。表の注記のとおり、一部のタイムゾーンでは、特定の日付範囲の時間値が正しく報告さない場合があります。オーストラリアのタイムゾーンの場合、返されるタイムゾーンの略名は、表の注記のとおり古い値になります。

[タイムゾーン]

コメント

Africa/Harare

このタイムゾーン設定では、1903 年 2 月 28 日 21:49:40 GMT から 1903 年 2 月 28 日 21:55:48 GMT まで正しくない値を返す可能性があります。

Africa/Monrovia

Africa/Nairobi

このタイムゾーン設定では、1939 年 12 月 31 日 21:30:00 GMT から 1959 年 12 月 31 日 21:15:15 GMT まで正しくない値を返す可能性があります。

Africa/Windhoek

America/Bogota

このタイムゾーン設定では、1914 年 11 月 23 日 04:56:16 GMT から 1914 年 11 月 23 日 04:56:20 GMT まで正しくない値を返す可能性があります。

America/Caracas

America/Chihuahua

America/Cuiaba

America/Denver

America/Fortaleza

America/Guatemala

America/Halifax

このタイムゾーン設定では、1918 年 10 月 27 日 05:00:00 GMT から 1918 年 10 月 31 日 05:00:00 GMT まで正しくない値を返す可能性があります。

America/Manaus

America/Matamoros

America/Monterrey

America/Montevideo

America/Phoenix

America/Tijuana

Asia/Ashgabat

Asia/Baghdad

Asia/Baku

Asia/Bangkok

Asia/Beirut

Asia/Calcutta

Asia/Kabul

Asia/Karachi

Asia/Kathmandu

Asia/Muscat

このタイムゾーン設定では、1919 年 12 月 31 日 20:05:36 GMT から 1919 年 12 月 31 日 20:05:40 GMT まで正しくない値を返す可能性があります。

Asia/Riyadh

このタイムゾーン設定では、1947 年 3 月 13 日 20:53:08 GMT から 1949 年 12 月 31 日 20:53:08 GMT まで正しくない値を返す可能性があります。

Asia/Seoul

このタイムゾーン設定では、1904 年 11 月 30 日 15:30:00 GMT から 1945 年 9 月 7 日 15:00:00 GMT まで正しくない値を返す可能性があります。

Asia/Shanghai

このタイムゾーン設定では、1927 年 12 月 31 日 15:54:08 GMT から 1940 年 6 月 2 日 16:00:00 GMT まで正しくない値を返す可能性があります。

Asia/Singapore

Asia/Taipei

このタイムゾーン設定では、1937 年 9 月 30 日 16:00:00 GMT から 1979 年 9 月 29 日 15:00:00 GMT まで正しくない値を返す可能性があります。

Asia/Tehran

Asia/Tokyo

このタイムゾーン設定では、1937 年 9 月 30 日 15:00:00 GMT から 1937 年 12 月 31 日 15:00:00 GMT まで正しくない値を返す可能性があります。

Asia/Ulaanbaatar

Atlantic/Azores

このタイムゾーン設定では、1911 年 5 月 24 日 01:54:32 GMT から 1912 年 1 月 1 日 01:54:32 GMT まで正しくない値を返す可能性があります。

Australia/Adelaide

このタイムゾーンの略名は ACDT/ACST ではなく CST として返されます。

Australia/Brisbane

このタイムゾーンの略名は AEDT/AEST ではなく EST として返されます。

Australia/Darwin

このタイムゾーンの略名は ACDT/ACST ではなく CST として返されます。

Australia/Hobart

このタイムゾーンの略名は AEDT/AEST ではなく EST として返されます。

Australia/Perth

このタイムゾーンの略名は AWDT/AWST ではなく WST として返されます。

Australia/Sydney

このタイムゾーンの略名は AEDT/AEST ではなく EST として返されます。

Brazil/East

Canada/Saskatchewan

このタイムゾーン設定では、1918 年 10 月 27 日 08:00:00 GMT から 1918 年 10 月 31 日 08:00:00 GMT まで正しくない値を返す可能性があります。

Europe/Amsterdam

Europe/Athens

Europe/Dublin

Europe/Helsinki

このタイムゾーン設定では、1921 年 4 月 30 日 22:20:08 GMT から 1921 年 4 月 30 日 22:20:11 GMT まで正しくない値を返す可能性があります。

Europe/Paris

Europe/Prague

Europe/Sarajevo

Pacific/Auckland

Pacific/Guam

Pacific/Honolulu

このタイムゾーン設定では、1933 年 5 月 21 日 11:30:00 GMT から 1945 年 9 月 30 日 11:30:00 GMT まで正しくない値を返す可能性があります。

Pacific/Samoa

このタイムゾーン設定では、1911 年 1 月 1 日 11:22:48 GMT から 1950 年 1 月 1 日 11:30:00 GMT まで正しくない値を返す可能性があります。

US/Alaska

US/Central

US/Eastern

US/East-Indiana

US/Pacific

UTC

Amazon Aurora と Amazon RDS for MySQL の比較

Aurora インスタンスは MySQL クライアントアプリケーションと互換性がありますが、Aurora には、MySQL にはない利点と、Aurora がサポートする MySQL 機能に対する制約があります。この機能性は、Amazon Aurora と MySQL on Amazon RDS のどちらがお客様のソリューションに最適のクラウドデータベースであるかの決定要因になる可能性があります。次の表は、Amazon Aurora と Amazon RDS for MySQL の違いを示しています。

機能 Amazon Aurora Amazon RDS for MySQL
読み取りのスケーリング 最大 15 個の Aurora レプリカをサポート。書き込みオペレーションのパフォーマンスに対する影響は最小限。 最大 5 個のリードレプリカをサポート。書き込みオペレーションのパフォーマンスに対する影響は顕著。
フェイルオーバーターゲット Aurora レプリカが自動フェイルオーバーターゲット。データ損失なし。 リードレプリカは、データ損失の可能性がある場合、マスター DB インスタンスに手動で昇格させることができます。
MySQL のバージョン MySQL のバージョン 5.6 のみをサポート。 MySQL のバージョン 5.5、5.6、および 5.7 をサポート。
AWS リージョン Aurora DB クラスターは以下のリージョンでのみ作成することができます。米国東部(バージニア北部) (us-east-1)、米国東部 (オハイオ) (us-east-2)、米国西部 (オレゴン) (us-west-2)、アジアパシフィック (ムンバイ) (ap-south-1)、アジアパシフィック (ソウル) (ap-northeast-2)、アジアパシフィック (シドニー) (ap-southeast-2)、アジアパシフィック (東京) (ap-northeast-1)、カナダ (中部) (ca-central-1)、欧州 (アイルランド) (eu-west-1)、欧州 (ロンドン) (eu-west-2) すべての AWS リージョンで使用できます。
MySQL ストレージエンジン

InnoDB のみサポート。他のストレージエンジンのテーブルは自動的に InnoDB に変換されます。

既存の MySQL テーブルの InnoDB への変換と Aurora クラスターへのインポートについては、「Amazon Aurora DB クラスターへのデータの移行」を参照してください。

Amazon Aurora では、InnoDB エンジンのみをサポートしているため、SQL_MODE データベースパラメータの NO_ENGINE_SUBSTITUTION オプションが有効です。これにより、そのテーブルが TEMPORARY と指定されていない場合、メモリ内テーブルを作成する機能が無効になります。

MyISAM と InnoDB の両方をサポート。
マスターインスタンスとは異なるストレージエンジンでのリードレプリカ Aurora DB クラスターでレプリケートする MySQL (非 RDS) のリードレプリカのみが InnoDB を使用できます。 リードレプリカは MyISAM と InnoDB の両方を使用できます。
データベースエンジンのパラメータ 一部のパラメータは、Aurora DB クラスター全体に適用され、DB クラスターパラメータグループ単位で管理されます。DB クラスターの個々の DB インスタンスに適用され、DB パラメータグループ単位で管理されるパラメータもあります。詳細については、「DB クラスターパラメータと DB インスタンスパラメータ」を参照してください。 パラメータは、個々の DB インスタンスまたはリードレプリカに適用され、DB パラメータグループ単位で管理されます。