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

プレビュー - PostgreSQL と互換性を持つ Amazon Aurora

Amazon Relational Database Service (Amazon RDS) は、PostgreSQL との互換性がある Amazon Aurora、Aurora (PostgreSQL) をプレビューしています。Aurora は、PostgreSQL および MySQL と互換がある、完全マネージド型のリレーショナルデータベースエンジンです。ハイエンドの商用データベースの処理速度や信頼性だけでなく、オープンソースデータベースの簡素性やコスト効率をあわせ持っています。Aurora の完全な概要については、「Amazon Aurora の概要」を参照してください。

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

Aurora (PostgreSQL) に登録するには、「https://pages.awscloud.com/amazon-aurora-with-postgresql-compatibility-preview-form.html」のプレビューのサインアップ用リンクにアクセスします。登録が完了すると、プレビュー Aurora (PostgreSQL) インスタンスを作成可能な、サンドボックス化された AWS リージョンにアクセスできるようになります。プレビュー実施時にプレビューデータベースで使用されたプレビューデータベースインスタンスまたはストレージに対する料金は発生しません。

Aurora (PostgreSQL) のプレビューには、以下の制限があります。

  • プレビュープログラム時の使用可能時間と可用性に関する契約はありません。

  • PostgreSQL 9.6.2 と互換性があること

  • 現在プレビューでは、DB インスタンスクラス (db.r3.8xlarge、db.r4.4xlarge、db.r4.8xlarge、db.r4.16xlarge) をサポートしています。

  • アカウントにつき最大 3 個のインスタンスを作成できます。

  • リードノードがサポートされるようになりました。

  • 2 フェーズのコミットは現在サポートされていません。

  • PostgreSQL 9.6.2 で現在サポートされている拡張機能はすべて、例外なく、プレビューでサポートされます。

  • Amazon EC2 の Amazon EBS ボリュームを使用して PostgreSQL と比較すると、パフォーマンスは、1~2 倍の速度になります。

現在、Amazon Aurora の複数の機能は、このプレビュー時に使用することはできませんが、Aurora (PostgreSQL) が一般公開されると利用できるようになります。次の機能があります。

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

  • PostgreSQL DB インスタンスの Amazon RDS からの DB スナップショットのインポート

Aurora (PostgreSQL) DB クラスターの作成

Aurora (PostgreSQL) DB クラスターは、PostgreSQL と、3 つのアベイラビリティーゾーンにコピーされたデータを単一の仮想ボリュームとして表現するクラスターボリュームと互換性があるインスタンスで構成されます。DB クラスターには、プライマリインスタンスAurora レプリカの 2 種類のインスタンスがあります。

プライマリインスタンスは、DB クラスターに対するすべてのデータ変更を実行し、さらに読み取りワークロードをサポートします。各 DB クラスターには 1 つのプライマリインスタンスがあります。Aurora レプリカは読み取りワークロードのみをサポートします。各 DB インスタンスは、最大 15 個の Aurora レプリカを持つことができます。エンドポイントアドレスを使用して DB クラスターのすべてのインスタンスに接続できます。

次に、Aurora (PostgreSQL) DB クラスターを作成し、その DB クラスターの Aurora レプリカを追加する方法を説明します。DB クラスターを作成する前に、「Amazon RDS のセットアップ」セクションのタスクを完了する必要があります。

以下の手順は、AWS マネジメントコンソール を使用して、Aurora (PostgreSQL) DB クラスターを作成する方法を示しています。Aurora DB クラスターへの接続に関する簡単な説明については、「Amazon Aurora DB クラスターへの接続」を参照してください。Aurora (PostgreSQL) DB クラスターへの接続に関する詳しいガイドについては、「RDS Aurora 接続」を参照してください。

DB クラスターの前提条件

DB クラスターを作成するための前提条件を次に示します。

VPC

Aurora (PostgreSQL) DB クラスターは、最低 2 つのアベイラビリティーゾーンに最低 2 つのサブネットがある Amazon Virtual Private Cloud (Amazon VPC) にのみ作成できます。少なくとも 2 つのアベイラビリティーゾーンにまたがってクラスターインスタンスを配信することで、ごく稀にアベイラビリティーゾーンに障害が発生した場合でも、DB クラスター内で使用できるインスタンスを確保できます。データ損失の可能性を低減し、耐久性のあるストレージを提供するために、Aurora の DB クラスターのクラスターボリュームは常に 3 つのアベイラビリティーゾーンにまたがっています。

Amazon RDS コンソールを使用して Aurora (PostgreSQL) DB クラスターを作成する場合、お客様に代わって Amazon RDS に VPC を自動的に作成させることができます。または、既存の VPC を使うか、Aurora DB クラスター用に新しい VPC を作成することができます。VPC を Aurora (PostgreSQL) DB クラスターで使用するには、VPC にサブネットが少なくとも 2 つ必要です。詳細については、「Amazon Aurora で使用する VPC を作成する方法」を参照してください。VPC の詳細については、「Amazon Virtual Private Cloud (VPCs) と Amazon RDS」を参照してください。

注記

ClassicLink を使用すると、VPC にない EC2 インスタンスと、Amazon Aurora DB クラスターとの通信が可能になります。詳細については、「VPC 内の DB インスタンスに VPC 外の EC2 インスタンスがアクセスする」を参照してください。

デフォルト VPC を持っていない、または VPC を作成していない場合は、RDS コンソールを使用して Aurora (PostgreSQL) DB クラスターを作成するときに、お客様に代わって Amazon RDS に VPC を自動的に作成させることができます。それ以外の場合は、以下を実行する必要があります。

  • 最低 2 つのアベイラビリティーゾーンの中に最低 2 つのサブネットを持つ VPC を作成します。

  • Aurora DB クラスターへの接続を許可する VPC セキュリティグループを指定します。詳細については、VPC の DB インスタンスの使用 を参照してください。

  • Aurora DB クラスターが使用できる VPC 内の最低 2 つのサブネットを定義する RDS DB サブネットグループを指定します。詳細については、『Amazon Virtual Private Cloud (VPCs) と Amazon RDS』の「DB サブネットグループの操作」を参照してください。

追加前提条件

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

    IAM アカウントを使用して Amazon Aurora コンソールにアクセスする場合は、まず、IAM アカウントで AWS マネジメントコンソール コンソールにサインインする必要があります。サインインすると、プレビュー登録時に送信された Amazon RDS コンソールのリンクにアクセスできるようになります。

  • DB クラスターの構成パラメータを調整する場合は、必要なパラメータ設定を持つ DB パラメータグループを指定する必要があります。DB パラメータグループの作成または変更については、「DB パラメータグループを使用する」を参照してください。

  • DB クラスター用に指定する TCP/IP ポート番号を決定する必要があります。会社のファイアウォールによっては、デフォルトの Aurora (PostgreSQL) ポート (5432) への接続がブロックされる場合があります。会社のファイアウォールがデフォルトのポートをブロックする場合は、お客様の DB クラスター用に別のポートを選択します。DB クラスターのすべてのインスタンスは同じポートを使用します。

AWS マネジメントコンソール を使用した Aurora (PostgreSQL) DB クラスターの起動と Aurora レプリカの作成

Aurora DB クラスターの起動

次の手順は、AWS マネジメントコンソール を使用した Aurora (PostgreSQL) DB クラスターの起動方法と、プレビュー時の Aurora レプリカの作成方法を示しています。

コンソールを使用して Aurora (PostgreSQL) DB クラスターを起動するには

  1. プレビュー登録時に送信された Amazon RDS コンソールのリンクを開きます。[Get Started Now] を選択します。

  2. AWS マネジメントコンソール の右上隅で、DB クラスターを作成するリージョンを選択します。

  3. ナビゲーションペインで、[Instances] を選択します。

  4. [Launch DB Instance] を選択して、DB インスタンス起動ウィザードを開始します。ウィザードが起動し、[Select Engine] ページが開きます。

  5. [Select Engine] ページで、Aurora (PostgreSQL) DB エンジンの [Select] を選択します。

  6. [Specify DB Details] ページで、DB クラスターの情報を指定します。次の表は、Aurora (PostgreSQL) DB インスタンスの設定を示しています。

    使用するオプション 操作

    DB インスタンスクラス

    DB クラスターの各インスタンスに対する処理要件やメモリ要件を定義する DB インスタンスクラスを選択します。このプレビューで、Amazon (PostgreSQL) は、DB インスタンスクラス (db.r4.4xlarge、db.r4.8xlarge、db.r4.16xlarge、db.r3.8xlarge) をサポートしています。DB インスタンスクラスのオプションについては、「DB インスタンスクラス」を参照してください。

    マルチ AZ 配置

    フェイルオーバーのサポート用に他のアベイラビリティーゾーンで Aurora レプリカを作成するかどうかを決めます。[Create Replica in Different Zone] を選択した場合、Amazon RDS は使用している DB クラスターのプライマリインスタンスではなく、別のアベイラビリティーゾーンの DB クラスターの Aurora レプリカを作成します。

    複数のアベイラビリティーゾーンの詳細については、「リージョンとアベイラビリティーゾーン」を参照してください。

    DB Instance Identifier

    DB クラスターのプライマリインスタンスの名前を入力します。この識別子は、DB クラスターのプライマリインスタンスのエンドポイントアドレスで使用されます。

    DB インスタンス識別子には次の制約があります。

    • 1 ~ 63 文字の英数字またはハイフンを使用する必要があります。

    • 1 字目は文字である必要があります。

    • ハイフンを、文字列の最後に使用したり、2 つ続けて使用したりすることはできません。

    • リージョン内の各 AWS アカウントのすべての DB インスタンスにおいて、一意である必要があります。

    Master Username

    DB クラスターにログオンするためのマスターユーザー名を英数字で入力します。

    Master Password

    マスターユーザーのパスワードを 8 ~ 41 文字で入力します。使用できるのは印刷可能な ASCII 文字 (/、"、@ を除く) です。

  7. [Next] を選択します。

  8. [Configure Advanced Settings] ページで、Aurora (PostgreSQL) DB クラスターのその他の設定をカスタマイズできます。次の表は、DB クラスターの詳細設定を示しています。

    使用するオプション 操作

    VPC

    DB クラスターをホストする VPC を選択します。[Create a New VPC] を選択して、Amazon RDS で VPC を作成します。詳細については、このトピックで前述した「DB クラスターの前提条件」を参照してください。

    サブネットグループ

    DB クラスターで使用する DB サブネットグループを選択します。[Create a New DB Subnet Group] を選択し、Amazon RDS で DB サブネットグループを作成します。詳細については、このトピックで前述した「DB クラスターの前提条件」を参照してください。

    パブリックアクセス可能

    DB クラスターにパブリック IP アドレスを指定するには [Yes] を選択します。それ以外の場合は [No] を選択します。DB クラスターのインスタンスでは、パブリック DB インスタンスとプライベート DB インスタンスの両方を混在させることができます。パブリックアクセスからインスタンスを隠す方法については、「VPC の DB インスタンスをインターネットから隠す」を参照してください。

    アベイラビリティーゾーン

    特定のアベイラビリティーゾーンを指定するかどうかを指定します。利用可能ゾーンについての詳細は、リージョンとアベイラビリティーゾーン を参照してください。

    VPC セキュリティグループ

    DB クラスターへのネットワークアクセスの保護用に 1 つ以上の VPC セキュリティグループを選択します。[Create a New VPC Security Group] を選択して、Amazon RDS で VPC セキュリティグループを作成します。詳細については、このトピックで前述した「DB クラスターの前提条件」を参照してください。

    DB クラスター識別子

    DB クラスターの名前を入力します。この名前は選択したリージョン内で、お客様のアカウントに対して一意である必要があります。この識別子は、DB クラスターのクラスターエンドポイントアドレスで使用されます。クラスターエンドポイントの詳細については、「Aurora エンドポイント」を参照してください。

    DB クラスター識別子には以下の制約があります。

    • 1 ~ 63 文字の英数字またはハイフンを使用する必要があります。

    • 1 字目は文字である必要があります。

    • ハイフンを、文字列の最後に使用したり、2 つ続けて使用したりすることはできません。

    • 各リージョンの各 AWS アカウントのすべての DB クラスターの中で一意である必要があります。

    Database Name

    デフォルトデータベースの名前を英数字 8 文字以内で入力します。名前の指定がない場合、Amazon RDS は DB クラスターにデータベースを作成しません。

    追加のデータベースを作成するには、DB クラスターに接続し、SQL コマンド CREATE DATABASE を使用します。DB クラスターへの接続の詳細については、「Amazon Aurora DB クラスターへの接続」を参照してください。

    Database Port

    データベースにアクセスするためにアプリケーションやユーティリティで使用されるポートを指定します。Aurora (PostgreSQL) DB クラスターのデフォルトの PostgreSQL ポートは 5432 になります。会社のファイアウォールによっては、デフォルトの PostgreSQL ポートへの接続がブロックされる場合があります。会社のファイアウォールがデフォルトのポートをブロックする場合は、新しい DB クラスター用に別のポートを選択します。

    パラメータグループ

    パラメータグループを選択します。Aurora にはデフォルトのパラメータグループが用意されています。また、独自のパラメータグループを作成することもできます。パラメータグループの詳細については、「DB パラメータグループを使用する」を参照してください。

    Option Group

    オプショングループを選択します。Aurora にはデフォルトのオプショングループが用意されています。また、独自のオプショングループを作成することもできます。オプショングループの詳細については、「オプショングループを使用する」を参照してください。

    暗号を有効化

    このプレビューでは、[No] を選択します。詳細については、「Amazon RDS リソースの暗号化」を参照してください。

    優先度

    インスタンスのフェイルオーバー優先度を選択します。値を選択しない場合、デフォルト値は tier-1 になります。この優先度により、プライマリインスタンスの障害からの復旧時に、Aurora レプリカを昇格する順序が決まります。詳細については、「Aurora DB クラスターの耐障害性」を参照してください。

    バックアップの保存期間

    Aurora がデータベースのバックアップコピーを保持する期間 (1 ~ 35 日) を選択します。バックアップコピーは、2 番目のデータベースに対するポイントインタイム復元 (PITR) で使用できます。

    Enable Enhanced Monitoring

    DB クラスターが実行されているオペレーティングシステムに対してリアルタイムでのメトリクスの収集を有効にするには、[Yes] を選択します。詳細については、「拡張モニタリング」を参照してください。

    詳細度

    [Enable Enhanced Monitoring] が [Yes] に設定されている場合にのみ使用できます。DB クラスターのメトリクスを収集する間隔を秒単位で設定します。

    Auto Minor Version Upgrade

    このプレビューでは、[No] を選択します。

    メンテナンス時間

    週 1 回のシステムメンテナンスを実行できる時間帯を選択します。

  9. [Launch DB Instance] を選択して Aurora (PostgreSQL) DB インスタンスを起動し、[Close] を選択してウィザードを閉じます。

    Amazon RDS コンソールでは、新しい DB インスタンスが DB インスタンスのリストに表示されます。DB インスタンスが作成されて使用できるようになるまで、DB インスタンスのステータスは creating となります。ステータスが [available] に変わったら、DB クラスターのプライマリインスタンスに接続できます。DB インスタンスクラスと割り当てられたストレージによっては、新しいインスタンスを使用できるようになるまで数分かかることがあります。

    新しく作成したクラスターを表示するには、Amazon RDS コンソールで [Clusters] ビューを選択します。詳細については、「Amazon Aurora DB クラスターの表示」を参照してください。

     Amazon Aurora DB インスタンスリスト

    クラスターのポートとエンドポイントをメモします。クラスターのエンドポイントとポートは、書き込みまたは読み取りオペレーションを実行するすべてのアプリケーション用の JDBC 接続文字列と ODBC 接続文字列で使用します。

コンソールを使用した Aurora レプリカの作成

Aurora DB クラスターのプライマリインスタンスを作成した後、[Create Aurora Replica] ウィザードを使用して、最大 15 個の Aurora レプリカを追加できます。

AWS マネジメントコンソールを使用して Aurora レプリカを作成するには

  1. プレビュー登録時に送信された Amazon RDS コンソールのリンクを開きます。

  2. 左のナビゲーションペインの [Instances] を選択します。

  3. Aurora DB クラスターのプライマリインスタンスの左側にあるチェックボックスを選択してオンにします。

  4. [Instance Actions] を選択し、[Create Aurora Replica] を選択します。

  5. [Create Aurora Replica] ページで、Aurora レプリカのオプションを指定します。次の表は、Aurora レプリカの設定を示しています。

    使用するオプション 操作

    DB インスタンスクラス

    Aurora レプリカの処理要件やメモリ要件を定義する DB インスタンスクラスを選択します。このプレビューでは、Aurora (PostgreSQL) は、DB インスタンスクラス (db.r4.4xlarge、db.r4.8xlarge、db.r4.16xlarge、db.r3.8xlarge) をサポートしています。DB インスタンスクラスのオプションについては、「DB インスタンスクラス」を参照してください。

    Aurora レプリカのソース

    Aurora レプリカを作成するプライマリインスタンスの識別子を選択します。

    DB Instance Identifier

    インスタンス名を入力します。選択したリージョン内で、自分のアカウントに対して一意であることが必要です。名前には、選択したリージョンと DB エンジンなどを含めると理解しやすくなります (例: aurora-read-instance1)。

    パブリックアクセス可能

    Aurora レプリカにパブリック IP アドレスを割り当てるには [Yes] を選択します。それ以外の場合は [No] を選択します。Aurora レプリカをパブリックアクセスから隠す方法については、「VPC の DB インスタンスをインターネットから隠す」を参照してください。

    アベイラビリティーゾーン

    特定のアベイラビリティーゾーンを指定するかどうかを指定します。リストには、先に指定した DB サブネットグループによってマッピングされたアベイラビリティーゾーンのみが含まれます。利用可能ゾーンについての詳細は、リージョンとアベイラビリティーゾーン を参照してください。

    優先度

    インスタンスのフェイルオーバー優先度を選択します。値を選択しない場合、デフォルト値は tier-1 になります。この優先度により、プライマリインスタンスの障害からの復旧時に、Aurora レプリカを昇格する順序が決まります。詳細については、「Aurora DB クラスターの耐障害性」を参照してください。

    Database Port

    Aurora レプリカのポートは、DB クラスターのポートと同じです。

    Auto Minor Version Upgrade

    このプレビューでは、[No] を選択します。

  6. Aurora レプリカを作成するには、[Create Aurora Replica] を選択します。

Aurora レプリカのエンドポイントをメモします。Aurora レプリカのエンドポイントは、読み取りオペレーションのみを実行するすべてのアプリケーション用の JDBC 接続文字列と ODBC 接続文字列で使用します。

Amazon Aurora DB クラスターへの接続

Aurora DB インスタンスには、PostgreSQL データベースに接続するために使用するものと同じツールを使用して接続できます。このプロセスの一部として、Secure Sockets Layer (SSL) 接続の場合と同じ公開鍵を使用します。Amazon Aurora DB クラスターのプライマリインスタンスまたは Aurora レプリカのエンドポイントとポート情報を、PostgreSQL インスタンスに接続するすべてのスクリプト、ユーティリティ、またはアプリケーションの接続文字列の中で使用できます。接続文字列では、プライマリインスタンスまたは Aurora レプリカのエンドポイントの DNS アドレスをホストパラメータとして指定し、エンドポイントのポート番号をポートパラメータとして指定します。

Amazon Aurora DB クラスターに接続すると、PostgreSQL バージョン 9.6.2 と互換性のある SQL コマンドを実行できます。

Amazon Aurora DB クラスターへの接続に役立つ詳しいガイドについては、「RDS Aurora 接続」を参照してください。

DB クラスターの詳細ビューで、クラスターエンドポイントを確認できます。このエンドポイントは、PostgreSQL 接続文字列で使用します。エンドポイントは DB クラスターのドメイン名とポートで構成されます。たとえば、エンドポイントの値が mycluster.cluster-123456789012.us-east-1.rds.amazonaws.com:3306 の場合、PostgreSQL 接続文字列には次の値を指定します。

  • ホストまたはホスト名には mycluster.cluster-123456789012.us-east-1.rds.amazonaws.com を指定します

  • ポートには、5432、または DB クラスター作成時に使用したポート値を指定します。

クラスターエンドポイントは DB クラスターのプライマリインスタンスに接続します。このクラスターエンドポイントを使用して、読み取りと書き込みの両方のオペレーションを実行できます。DB クラスターは、DB クラスターのデータへの読み取り専用アクセスをサポートする、最大 15 個の Aurora レプリカを使用できます。プライマリインスタンスと各 Aurora のレプリカには、それぞれ、クラスターエンドポイントとは別に一意のエンドポイントが含まれます。一意のエンドポイントを使用することで、クラスターの特定の DB インスタンスに直接接続できるようになります。クラスターエンドポイントは常にプライマリインスタンスをポイントします。プライマリインスタンスが失敗し、置き換えられると、クラスターエンドポイントは新しいプライマリインスタンスをポイントします。

 Amazon Aurora DB インスタンス起動ウィザードでの Aurora レプリカ DB インスタンスの作成

Aurora (PostgreSQL) 接続障害のトラブルシューティング

注記

Amazon Aurora DB クラスターへの接続に役立つ詳しいガイドについては、「RDS Aurora 接続」を参照してください。

新しい Aurora DB クラスターに対する接続障害の一般的な原因を次に示します。

  • DB クラスターが、お使いのデバイスからの接続を許可しない VPC を使用して作成されています。この問題を解決するには、お使いのデバイスからの接続を許可するように VPC を変更するか、お使いのデバイスからの接続を許可する DB クラスターの新しい VPC を作成します。例については、「VPC とサブネットを作成する」を参照してください。

  • DB クラスターは、社内ネットワークのデバイスからそのポートへの接続をブロックするファイアウォールルールを持つポート値を使用して作成されています。この問題を解決するには、別のポートでインスタンスを再起動します。

Aurora (PostgreSQL) の高速フェイルオーバーベストプラクティス

Aurora (PostgreSQL) でフェイルオーバーをより高速で実行するには、いくつかの方法があります。このセクションでは、次の方法のそれぞれについて説明します。

  • TCP のキープアライブの積極的な実行として設定することで、失敗イベントとして読み込みタイムアウトの時間切れになる前に、サーバーの回答待ちにより実行時間が長いクエリを終了します。

  • Java DNS キャッシュタイムアウトを積極的な実行として設定することで、Aurora の読み込み専用エンドポイントが繰り返される接続試行の読み込み専用ノードで適切にサイクルすることを確実にします。

  • JDBC 接続文字列で使用されるタイムアウト変数をできるだけ低く設定します。短期間の実行クエリと長期間の実行クエリに対して、別々の接続オブジェクトを使用します。

  • 指定される Aurora エンドポイントの読み書きを使用することで、クラスターへの接続を確立します。

  • サーバー側の失敗のテストアプリケーション回答には RDS API を使用し、クライアント側の失敗のテストアプリケーション回答にはパケットドロップツールを使用します。

TCP キープアライブパラメータの設定

TCP キープアライブのプロセスは簡単です。TCP 接続を設定するには、一連のタイマーを関連付けます。キープアライブタイマーがゼロに達したら、キープアライブプローブパケットを送信します。キープアライブプローブに回答を受信した場合、接続が引き続き確立され、稼働中であると推測できます。

TCP キープアライブパラメータを有効化して積極的な実行に設定することで、クライアントがデータベースに接続できなくなった場合に、すべての有効な接続が速やかに切断されることを確実にします。このアクションは、アプリケーションが接続できる新しいホストを選択するなどの適切な対応を可能にします。

以下の TCP キープアライブパラメータは、次のように設定する必要があります。

  • tcp_keepalive_time は、ソケットからデータが送信されない場合に (ACK はデータと見なされません)、キープアライブが送信されてからの秒単位の時間を制御します。次の設定が推奨されます。

    tcp_keepalive_time = 1

  • tcp_keepalive_intvl は、最初のキープアライブパケットが送信されてから引き続きのパケットが送信されるまでの時間を秒単位で制御します (tcp_keepalive_time パラメータを使用して設定)。次の設定が推奨されます。

    tcp_keepalive_intvl = 1

  • tcp_keepalive_probes は、アプリケーションに通知される前に発生する、認知されていないキープアライブプローブ数です。次の設定が推奨されます。

    tcp_keepalive_probes = 5

この設定で、データベースの応答が停止してから 5 秒後以内にアプリケーションに通知します。アプリケーションネットワークでキープアライブがドロップする頻度が高い場合には、tcp_keepalive_probes 値をより高く設定できます。tcp_keepalive_probes 値をより高い値に設定すると、実際の失敗を検出するための時間が長くなりますが、信頼度が低いネットワークへの不要なフェイルオーバーを減少するために役立ちます。

Linux で TCP キープアライブパラメータを設定する

  1. TCP キープアライブパラメータを設定する方法をテストする場合、次のコマンドのコマンドラインで実行することが推奨されます。この推奨設定はシステム全体となることに留意してください。つまり、SO_KEEPALIVE オプションがオンであるソケットを作成するほかのすべてのアプリケーションに影響します。

    Copy
    sudo sysctl net.ipv4.tcp_keepalive_time=1 sudo sysctl net.ipv4.tcp_keepalive_intvl=1 sudo sysctl net.ipv4.tcp_keepalive_probes=5
  2. アプリケーションで作動する設定を見つけたら、この設定を維持するために次のライン (と作成したすべての変更) を /etc/sysctl.conf に追加する必要があります。

    Copy
    tcp_keepalive_time = 1 tcp_keepalive_intvl = 1 tcp_keepalive_probes = 5

TCP キープアライブパラメータを Windows で設定するための詳細は、「Things You May Want to Know About TCP Keepalive」を参照してください。

高速フェイルオーバー用にアプリケーションを設定する

このセクションでは、いくつかの可能な Aurora (PostgreSQL) 専用の設定変更を説明します。JDBC ドライバーの一般的なセットアップと設定に関するドキュメントは、PostgreSQL JDBC site で参照できます。

DNS キャッシュタイムアウトの短縮

フェイルオーバー後にアプリケーションが接続の確立を試行するとき、新規の Aurora (PostgreSQL) プライマリ (読み書き) インスタンスは、クラスターの読み取り専用インスタンスの 1 つから選択されます。選択された新規のプライマリは、DNS の更新が完全に伝達される前に Aurora のリーダーエンドポイントを使用して見つけることができます。Java DNS TTL を低い値に設定すると、リーダーノード間における引き続く接続試行のサイクルに役立ちます。

Copy
// Sets internal TTL to match the Aurora RO Endpoint TTL java.security.Security.setProperty("networkaddress.cache.ttl" , "1"); // If the lookup fails, default to something like small to retry java.security.Security.setProperty("networkaddress.cache.negative.ttl" , "3");

Aurora (PostgreSQL) 接続文字列を高速フェイルオーバーに設定する

Aurora (PostgreSQL) フェイルオーバーを利用するには、アプリケーションの接続文字列にホストの一覧 (次の例の太字表示) が単一ホストの代わりにある必要があります。これが、Aurora (PostgreSQL) クラスターに接続するために使用できる接続文字列の例です。

Copy
jdbc:postgresql://myauroracluster.cluster-c9bfei4hjlrd.us-east-1-beta.rds.amazonaws.com:5432, myauroracluster.cluster-ro-c9bfei4hjlrd.us-east-1-beta.rds.amazonaws.com:5432 /postgres?user=<masteruser>&password=<masterpw>&loginTimeout=2 &connectTimeout=2&cancelSignalTimeout=2&socketTimeout=60 &tcpKeepAlive=true&targetServerType=master&loadBalanceHosts=true

最大限の可用性のため、RDS API への依存性を回避する目的で、接続に最適なオプションは、データベースに接続を確立したときにアプリケーションが読み込んだホスト文字列でファイルを維持することです。このホストの文字列にはクラスターで使用できるすべての Aurora エンドポイントがあります。Aurora エンドポイントの詳細については、「Aurora エンドポイント」を参照してください。たとえば、以下のように、エンドポイントをローカルのファイルに保存できます。

Copy
myauroracluster.cluster-c9bfei4hjlrd.us-east-1-beta.rds.amazonaws.com:5432, myauroracluster.cluster-ro-c9bfei4hjlrd.us-east-1-beta.rds.amazonaws.com:5432

アプリケーションは、このファイルを読み込んで JDBC 接続文字列のホストセクションを入力します。DB クラスターの名前を変更すると、このエンドポイントは変更します。このイベントが発生したことをアプリケーションが取り扱うように確認します。

もう 1 つのオプションは、DB インスタンスノードの一覧を使用することです。

Copy
my-node1.cksc6xlmwcyw.us-east-1-beta.rds.amazonaws.com:5432, my-node2.cksc6xlmwcyw.us-east-1-beta.rds.amazonaws.com:5432, my-node3.cksc6xlmwcyw.us-east-1-beta.rds.amazonaws.com:5432, my-node4.cksc6xlmwcyw.us-east-1-beta.rds.amazonaws.com:5432

この方法の利点は、Aurora のエンドポイントを使用すると、接続試行ごとに 2 つのノードだけ実行されるのに対して、PostgreSQL JDBC 接続ドライバーは有効な接続を見つけるためにこの一覧のすべてのノードからループすることです。DB インスタンスノードを使用するデメリットは、クラスターにノードを追加、または削除すると、インスタンスエンドポイントの一覧が古くなり、接続ドライバーが接続する接続ホストを見つけることができない場合があることです。

以下のパラメータを積極的に実行するよう設定すると、アプリケーションがいずれか 1 つのホストに接続するために必要以上の待機を行わないことを確保できます。

  • loginTimeout - ソケット接続が確立されたあとで、アプリケーションがデータベースにログインするための待機時間を制御します。

  • connectTimeout - ソケットがデータベースに接続を確立するまでの待機時間を制御します。

そのほかのアプリケーションパラメータでは、アプリケーションの希望する積極性に応じて、接続プロセスの高速化を変更できます。

  • cancelSignalTimeout - 一部のアプリケーションでは、タイムアウトがあるクエリで「ベストエフォート」型キャンセル信号を送信できます。このキャンセル信号がフェイルオーバーパスにある場合は、デッドホストにこの信号を送信しないように、この信号を積極的に設定することを検討してください。

  • socketTimeout - このパラメータは、ソケットが読み取り操作で待機する時間を制御します。このパラメータは、グローバルな「クエリタイムアウト」として使用でき、すべてのクエリがこの値以上待機しないことを確保します。グッドプラクティスとしては、短期のクエリを実行する 1 つの接続ハンドラーで値を低く設定し、長期実行のクエリには別の接続ハンドラーを用意して、その値をより高く設定します。こうして、サーバーがダウンした場合に、TCP キープアライブパラメータが長期間実行しているクエリを切断するようにできます。

  • tcpKeepAlive - このパラメータを有効にして、設定した TCP キープアライブパラメータが優先されることを確保します。

  • targetServerType- このパラメータは、ドライバーが読み込み (スレーブ) あるいは書き込み (マスター) ノードに接続するかを制御するために使用します。指定できる値は: anymasterslave preferSlavepreferSlave 値は、まずリーダーに接続の確立を試行して失敗し、確立できるリーダー接続がない場合にライターに接続します。

  • loadBalanceHosts - true に設定すると、このパラメータはアプリケーションを選択できるホストの一覧からランダムに選択されたホストに接続します。

ホスト文字列を取得するそのほかのオプション

replica_host_status テーブルを含めたいくつかのソースから、また Amazon RDS API を使用することでホスト文字列を取得できます。

アプリケーションは、DB クラスターのすべての DB インスタンスに接続でき、replica_host_status テーブルをクエリして、クラスターのライターを特定するか、またはクラスターのそのほかのリーダーノードを見つけることができます。このステータステーブルを使用することで、接続するホストを見つける時間数を短縮できます。ただし、replica_host_status テーブルは一部のネットワーク失敗シナリオで最新ではない、あるいは不完全な情報を表示する場合があります。

アプリケーションが接続するノードを見つけることを確実にするために良好な方法は、クラスターライターエンドポイントに接続を試行したのち、読み取りできる接続を確立できるまで、クラスターリーダーエンドポイントへの接続を試行します。これらのエンドポイントは、DB クラスターの名前を変更するまで変更しませんが、アプリケーションの静的メンバーとして一般的に残すか、アプリケーションが読み取るリソースファイルに保管することができます。

エンドポイントの 1 つを使用して接続が確立したら、ステータステーブルをクエリして残りのクラスターの情報を取得できます。たとえば、次のコマンドでは replica_host_status テーブルから情報を取得しています。

Copy
postgres=> select server_id, session_id, vdl, highest_lsn_rcvd, cur_replay_latency, now(), last_update_time from replica_host_status; server_id | session_id | vdl | highest_lsn_rcvd | cur_replay_latency | now | last_update_time -----------------------------------+--------------------------- -----------+-----------+------------------+--------------------+- ------------------------------+------- mynode-1 | 3e3c5044-02e2-11e7-b70d-95172646d6ca | 594220999 | 594221001 | 201421 | 2017-03-07 19:50:24.695322+00 | 2017-03-07 19:50:23+00 mynode-2 | 1efdd188-02e4-11e7-becd-f12d7c88a28a | 594220999 | 594221001 | 201350 | 2017-03-07 19:50:24.695322+00 | 2017-03-07 19:50:23+00 mynode-3 | MASTER_SESSION_ID | 594220999 | | | 2017-03-07 19:50:24.695322+00 | 2017-03-07 19:50:23+00 (3 rows)

接続文字列のホストセクションは、ライターとリーダークラスターエンドポイントの両方から開始できます。

Copy
myauroracluster.cluster-c9bfei4hjlrd.us-east-1-beta.rds.amazonaws.com:5432, myauroracluster.cluster-ro-c9bfei4hjlrd.us-east-1-beta.rds.amazonaws.com:5432

このシナリオでは、アプリケーションは、マスターまたはスレーブのすべてのノードタイプに接続の確立を試行します。接続したら、まずコマンド SHOW transaction_read_only を実行して、ノードの読み書きステータスを調べることが良好なプラクティスです。

返されるクエリの値が OFF の場合、マスターノードへの接続に成功しました。返される値が ON の場合、アプリケーションは読み書き接続を要求しています。replica_host_status テーブルをクエリして、server_idsession_id='MASTER_SESSION_ID' があることを判断します。このクエリは、マスターノードの名前を表示します。これは、以下に説明する「endpointPostfix」とともに使用できます。

注意すべき事項は、静的になったデータがあるレプリカに接続した場合です。この場合、replica_host_status テーブルは最新ではない情報を表示することがあります。古さのしきい値はアプリケーションレベルで設定でき、サーバー時間と更新時間の差異を見ることで確認できます。一般的にアプリケーションは、replica_host_status テーブルで情報が矛盾することによる 2 つ のホスト間での急変を確実に回避することが必要です。つまり、アプリケーションは、一途に replica_host_status テーブルに従う代わりに、まずすべての既知のホストを試行する側面でエラーとなる必要があります。

Amazon RDS API を使用して、ホスト文字列を見つける

インスタンスの一覧をプログラムによって見つけるには、AWS Java SDK を使用し、特に DescribeDbClusters API を使用します。以下に、java 8 でこれを行う方法の小さな例を紹介します。

Copy
AmazonRDS client = AmazonRDSClientBuilder.defaultClient(); DescribeDBClustersRequest request = new DescribeDBClustersRequest() .withDBClusterIdentifier(clusterName); DescribeDBClustersResult result = rdsClient.describeDBClusters(request); DBCluster singleClusterResult = result.getDBClusters().get(0); String pgJDBCEndpointStr = singleClusterResult.getDBClusterMembers().stream() .sorted(Comparator.comparing(DBClusterMember::getIsClusterWriter) .reversed()) // This puts the writer at the front of the list .map(m -> m.getDBInstanceIdentifier() + endpointPostfix + ":" + singleClusterResult.getPort())) .collect(Collectors.joining(","));

pgJDBCEndpointStr には、エンドポイントの形式一覧が含まれています。たとえば

Copy
my-node1.cksc6xlmwcyw.us-east-1-beta.rds.amazonaws.com:5432, my-node2.cksc6xlmwcyw.us-east-1-beta.rds.amazonaws.com:5432

「endpointPostfix」の変数を定数にして、クラスターの単一インスタンスへの DescribeDBInstances をクエリするようにアプリケーションを設定、または取得することができます。この値はリージョン内と単一のカスタマーにおいて一定となるため、アプリケーションが読み取るリソースファイルにこの定数を単に維持するように API 呼び出しを保存します。上記の例では、これは次のように設定されます。

Copy
.cksc6xlmwcyw.us-east-1-beta.rds.amazonaws.com

可用性目的では、API が応答しない、または応答時間が長すぎる場合に、DB クラスターの Aurora エンドポイント を使用するようにデフォルト設定することが良好なプラクティスです。エンドポイントは、DNS レコードを更新するためにかかる時間内で最新状態に保たれることが保証されます (通常、30 秒未満)。これもまた、アプリケーションが消費するリソースファイルに保存できます。

フェイルオーバーテスト

すべての場合において、2DB インスタンス以上の DB クラスターがあることが必要です。

サーバー側では、アプリケーションがどのように応答するかをテストするために使用する停止状態を一部の API で発生できます。

  • FailoverDBCluster - DB クラスターで新規の DB インスタンスをライターに昇格することを試行します。

    Copy
    public void causeFailover() { /* * See http://docs.aws.amazon.com/sdk-for-java/v1/developer-guide/basics.html for more details on setting up an RDS client */ final AmazonRDS rdsClient = AmazonRDSClientBuilder.defaultClient(); FailoverDBClusterRequest request = new FailoverDBClusterRequest(); request.setDBClusterIdentifier("cluster-identifier"); rdsClient.failoverDBCluster(request); }
  • RebootDBInstance - フェイルオーバーはこの API では保証されません。ただし、これはライターでデータベースをシャットダウンし、接続ドロップでアプリケーションがどのように応答するかをテストするために使用できます (ForceFailover パラメータは Aurora エンジンには適用されず、代わりに FailoverDBCluster API を使用する必要があることに注意してください)。

  • ModifyDBCluster - ポートを変更すると、新しいポートでクラスターのノードをリッスンし始めると停止が発生します。通常、アプリケーションのみがポート変更を制御することを確保し、依存するエンドポイントを適切に更新する、API レベルで変更を加えた時点で誰かが手動でポートを更新するようにする、またはポートが変更されているかを確認するためにアプリケーションで RDS API をクエリすることでアプリケーションはこの失敗に応答できます。

  • ModifyDBInstance - DBInstanceClass を変更すると、停止が発生します。

  • DeleteDBInstance -マスター/ライターを削除すると、新規の DB インスタンスが DB クラスターでライターに昇格します。

アプリケーション/クライアント側では、Linux を使用する場合に、tcp キープアライブパケットが iptables を使用して送信または受信されない場合、あるいはポート、ホストによってアプリケーションの応答がどのように突然パケットドロップするかをテストできます。

高速フェイルオーバーのベストプラクティスの例

以下のコードサンプルでは、アプリケーションがどのように Aurora (PostgreSQL) ドライブマネージャをセットアップできるかを示しています。アプリケーションは、接続が必要になると getConnection(...) を呼び出します。ライターが見つからないのに targetServer タイプは「マスター」) として設定されているなどの場合に、この関数への呼び出しは有効なホストの検出に失敗することがあり、呼び出しアプリケーションは単に再試行します。これは容易に接続プーラーに含めることができ、再試行動作がアプリケーションに与える影響を回避します。ほとんどの接続プーラーでは JDBC 接続文字列を指定できるため、アプリケーションは getJdbcConnectionString(...) を呼び出すことができ、これを接続プーラーに渡して、Aurora (PostgreSQL) の高速フェイルオーバーを使用できます。

Copy
import java.sql.Connection; import java.sql.DriverManager; import java.sql.SQLException; import java.sql.Statement; import java.util.ArrayList; import java.util.List; import java.util.stream.Collectors; import java.util.stream.IntStream; import org.joda.time.Duration; public class FastFailoverDriverManager { private static Duration LOGIN_TIMEOUT = Duration.standardSeconds(2); private static Duration CONNECT_TIMEOUT = Duration.standardSeconds(2); private static Duration CANCEL_SIGNAL_TIMEOUT = Duration.standardSeconds(1); private static Duration DEFAULT_SOCKET_TIMEOUT = Duration.standardSeconds(5); public FastFailoverDriverManager() { try { Class.forName("org.postgresql.Driver"); } catch (ClassNotFoundException e) { e.printStackTrace(); } /* * RO endpoint has a TTL of 1s, we should honor that here. Setting this aggressively makes sure that when * the PG JDBC driver creates a new connection, it will resolve a new different RO endpoint on subsequent attempts * (assuming there is > 1 read node in your cluster) */ java.security.Security.setProperty("networkaddress.cache.ttl" , "1"); // If the lookup fails, default to something like small to retry java.security.Security.setProperty("networkaddress.cache.negative.ttl" , "3"); } public Connection getConnection(String targetServerType) throws SQLException { return getConnection(targetServerType, DEFAULT_SOCKET_TIMEOUT); } public Connection getConnection(String targetServerType, Duration queryTimeout) throws SQLException { Connection conn = DriverManager.getConnection(getJdbcConnectionString(targetServerType, queryTimeout)); /* * A good practice is to set socket and statement timeout to be the same thing since both * the client AND server will kill the query at the same time, leaving no running queries * on the backend */ Statement st = conn.createStatement(); st.execute("set statement_timeout to " + queryTimeout.getMillis()); st.close(); return conn; } private static String urlFormat = "jdbc:postgresql://%s" + "/postgres" + "?user=%s" + "&password=%s" + "&loginTimeout=%d" + "&connectTimeout=%d" + "&cancelSignalTimeout=%d" + "&socketTimeout=%d" + "&targetServerType=%s" + "&tcpKeepAlive=true" + "&ssl=true" + "&loadBalanceHosts=true"; public String getJdbcConnectionString(String targetServerType, Duration queryTimeout) { return String.format(urlFormat, getFormattedEndpointList(getLocalEndpointList()), CredentialManager.getUsername(), CredentialManager.getPassword(), LOGIN_TIMEOUT.getStandardSeconds(), CONNECT_TIMEOUT.getStandardSeconds(), CANCEL_SIGNAL_TIMEOUT.getStandardSeconds(), queryTimeout.getStandardSeconds(), targetServerType ); } private List<String> getLocalEndpointList() { /* * As mentioned in the best practices doc, a good idea is to read a local resource file and parse the cluster endpoints. * For illustration purposes, the endpoint list is hardcoded here */ List<String> newEndpointList = new ArrayList<>(); newEndpointList.add("myauroracluster.cluster-c9bfei4hjlrd.us-east-1-beta.rds.amazonaws.com:5432"); newEndpointList.add("myauroracluster.cluster-ro-c9bfei4hjlrd.us-east-1-beta.rds.amazonaws.com:5432"); return newEndpointList; } private static String getFormattedEndpointList(List<String> endpoints) { return IntStream.range(0, endpoints.size()) .mapToObj(i -> endpoints.get(i).toString()) .collect(Collectors.joining(",")); } }