Failover Manager with EDB PgBouncer¶

Failover ManagerとEDB PgBouncerを使用して、オンプレミスのセットアップとクラウドのセットアップで高可用性を提供できます。 EDB PgBouncerは一般的な接続プーラーですが、マルチホスト構成、フェイルオーバー、または検出がないため、PostgreSQLの高可用性を単独で達成するには十分ではありません。

オンプレミスのEDB PgBouncerを使用したフェールオーバーマネージャー¶

オンプレミスセットアップの場合、接続ライブラリを使用して、複数のホストとの接続文字列を使用して高可用性を提供します。

Failover Manager using pgBouncer on-premises architecture diagram¶

図3：オンプレミスのEDB PgBouncerを使用したフェールオーバーマネージャーのトラフィックルーティング

クラウド内のEDB PgBouncerを備えたFailover Manager¶

クラウドセットアップの場合、ネットワークロードバランサー（NLB）を使用して、EDB PgBouncerの両方のインスタンスのトラフィックを分散します。

Failover Manager with PgBouncer cloud architecture diagram¶

図4：クラウドでEDB PgBouncerを使用したFailover Managerのトラフィックルーティング

EDBは、同じマシンで実行されているEDB PgBouncerとFailover Manager / PostgreSQLでは、このアーキテクチャをサポートしていません。

クラウドネットワークロードバランサー AzureでNLBを構成するによる制限

ソースと宛先が同じマシン上にある場合、トラフィックを適切にルーティングしません。

混合アーキテクチャでは、EDB PgBouncerとPostgres間のトラフィックがアンバランスになる場合があります（ローカルの場合も、ネットワークの場合もあります）。
EDB PgBouncerとPostgreSQLはリソースを競合します。
マスター障害は、ルーティング（EDB PgBouncer）とデータベースの両方に影響します。これらの2つのコンポーネントが同じマシンで結合されます。

PgBouncerでフェールオーバーマネージャーを使用する¶

インストール¶

次のように、AWS仮想マシンにAdvanced Serverデータベース、Failover Manager、およびEDB PgBouncerをインストールして構成します。

Systems	Components
PgDB srv 1, 2, 3	Primary / standby node running Advanced Server 13 and Failover Manager 4.2
PgBouncer srv 1, 2	PgBouncer node running EDB PgBouncer 1.15. Register these two nodes as targets in the target group. Two is the minimum and is sufficient for most cases.

フェールオーバーマネージャーの構成¶

Failover Manager documentation で提供されている手順を使用してください

フェールオーバーマネージャーを構成します。これらの手順に加えて、次の手順を実行します。

1.すべての（リモート）EDB PgBouncerホストに接続し、リダイレクトスクリプトを実行する統合スクリプトを作成します。 /usr/edb/efm-4.2/bin/efm_pgbouncer_functions でスクリプトを見つけます。ユーザーefmが次の内容のスクリプトを実行できることを確認します。

#!/bin/bash -x
set -e
IFS=,  read -r -a PGB_HOSTS <<< "$4"
FAILED_PGB_HOST=
for PGB_HOST in "${PGB_HOSTS[@]}"; do
    echo "redirecting to $2 on enterprisedb@${PGB_HOST}"
    if [ "$3" == "p" ]; then
       ssh "enterprisedb@${PGB_HOST}" /usr/edb/pgbouncer1.15/bin/redirect.sh "$2" || FAILED_PGB_HOST="$FAILED_PGB_HOST $PGB_HOST" < /dev/null
    fi
done

# return exit code to inform EFM agent about failure. The agent would send a failure
# notification accordingly for manual intervention
if [ ! -z "$FAILED_PGB_HOST" ]; then
   echo "Failed to redirect to $2 on $FAILED_PGB_HOST"
   exit 1
fi

2.各データベースノードで、 script.load.balancer.attach をefm プロパティファイルのカスタムスクリプトに設定します。

edb_notranlate_1 <pgbs1> はPgBouncerサーバー1のホスト名またはIPアドレスであり、 <pgbs2> はPgBouncerサーバー2のホスト名またはIPアドレスです。

PostgreSQLの構成¶

通常のオペレーション中、トラフィックは両方のPgBouncerインスタンス間で分散され、両方がPostgreSQLへの接続を開きます。したがって、PostgreSQLでは、両方のインスタンスから十分な接続を受け入れるようにmax_connections パラメーターが補償されていることを確認してください。

EDB PgBouncerの構成¶

EDB PgBouncer documentation で提供されている手順を使用できます

EDB PgBouncerを設定します。これらの手順に加えて、次の手順を実行します。

1.次の行をedb-pgbouncer-1.15.ini ファイルに追加します。

%include /etc/edb/pgbouncer1.15/edb-pgbouncer-databases.ini

edb-pgbouncer-1.15.ini ファイルで、 listen_addr の値を*に設定します。

listen_addr = *

edb-pgbouncer-1.15.ini ファイルの[databases]セクションを空のままにし、別のファイル/etc/edb/pgbouncer1.15/edb-pgbouncer-databases.ini でこのセクションを構成します。この追加の構成ファイルがenterprisedbによって読み取りおよび書き込み可能であることを確認します。

以下は、ファイルを作成するbashコマンドの例です。

echo "[databases]" > /etc/edb/pgbouncer1.15/edb-pgbouncer-databases.ini
echo "edb= host=srv1" >> /etc/edb/pgbouncer1.15/edb-pgbouncer-databases.ini
chown enterprisedb: /etc/edb/pgbouncer1.15/edb-pgbouncer-databases.ini

4.データベースの章を再構成し、pgbouncerをリロードするために使用するスクリプト/usr/edb/pgbouncer1.15/bin/redirect.sh を作成します。スクリプトの所有者がrootであること、およびuser/group/other（0755）に読み取りおよび実行アクセスがあることを確認してください。スクリプトの内容は次のとおりです。

#!/bin/bash
set -e

#Some defaults
PGBOUNCER_DATABASE_INI=/etc/edb/pgbouncer1.15/edb-pgbouncer-databases.ini

PGMSTR=${1:-localhost}

# enterprisedb user does not have permissions to write in folder directly, so `sed -i` will not work
TMPFILE=$(mktemp)
sed "s/host=[A-Za-z0-9.]*/host=${PGMSTR}/" "${PGBOUNCER_DATABASE_INI}" > "${TMPFILE}"
if ! diff -q "${PGBOUNCER_DATABASE_INI}" "${TMPFILE}" >/dev/null; then
    cat "${TMPFILE}" > "${PGBOUNCER_DATABASE_INI}"
    pkill -SIGHUP pgbouncer
fi

パスワードレスsshの構成¶

EDB PgBouncer統合では、パスワードなしのssh アクセスが必要です。 ssh を構成する方法は複数あります。組織の推奨プロセスに従って、パスワードなしのssh を構成します。クイックスタートとして、この例に従って、パスワードなしのssh を構成することもできます。ユーザーefm userは、PgBouncerを実行しているユーザーとしてsshできる必要があります。たとえば、enterprisedbなどです。

EDB PgBouncerホストで構成する¶

1.すべてのEDB PgBouncerホストで、enterprisedbユーザーのパスワードを一時的に設定します。 rootとしてpasswd enterprisedb を実行し、一時パスワードを2回入力します。

2.パスワードなしのssh が有効になっていることを確認します。次のコマンドで確認できます。

edb_notranlate_6 yes に設定されていることを確認します。必要に応じて変更し、ssh を再起動します。

フェールオーバーマネージャー/ PostgreSQLホストで構成する¶

すべてのフェールオーバーマネージャー/postgresホストで、 efmユーザーとして：

次のコマンドを実行します。

ssh-keygen -P "" -f ~/.ssh/id_rsa

2.すべてのEDB PgBouncerホストについて、次のコマンドでssh キーをコピーします。

edb_notranlate_8 enterprisedb ユーザーのデフォルトのホームディレクトリは/var/lib/edb です。このディレクトリがまだ存在しない場合は、手動で作成します。 sudoユーザーとして、各EDB PgBouncerホストで次のコマンドを実行します。

mkdir -p /var/lib/edb
chown -R enterprisedb:enterprisedb /var/lib/edb

EDB PgBouncerホストで一時パスワードをリセットする¶

rootとして次のコマンドを実行することにより、すべてのEDB PgBouncerホストでenterprisedbユーザーの一時パスワードをリセットできます。

shell passwd -d enterprisedb ### ネットワークロードバランサーの構成

AWSまたはAzureのネットワークロードバランサーを使用したFailover Manager EDB PgBouncer統合の場合、追加の手順を実行する必要があります。

EDB PgBouncerとデータベースインスタンスが使用するセキュリティグループに次のルールを追加します。

EDB PgBouncerインスタンス（SG PgBouncer）が使用するセキュリティグループのルール。

Type	Protocol	Port range	Source	Description
Custom TCP	TCP	6432	Entire Subnet	PgBouncer
Custom TCP	TCP	22	Entire Subnet	ssh

これらのルールに加えて、要件に応じてSSHとPingのルールを追加します。

データベースインスタンス(SG DB)が使用するセキュリティグループのルール：

Type	Protocol	Port range	Source	Description
Custom TCP	TCP	7800	Entire Subnet	フェールオーバーマネージャー
Custom TCP	TCP	5444	Entire Subnet	Postgres
Custom TCP	TCP	22	Entire Subnet	ssh

これらのルールにより、データベース、フェールオーバーマネージャー、およびEDB PgBouncerの実行に必要なポートが、トラフィックルーティングとヘルスモニタリングのためにノードとロードバランサー間の通信用に開かれます。

これらのルールに加えて、要件に応じてSSHとPingのルールを追加します。

AzureでNLBを構成する¶

AWSを使用している場合は、 AWSでNLBを設定するを参照してください。

Creating rules for security groups

で説明されているルールを構成した後、Azureのドキュメントに従って、次のことを行います。

EDB PgBouncerインスタンスを実行している2つの仮想マシンで構成されるバックエンドプールを作成します。仮想マシンのプライベート IP を使用して、バックエンドプールを作成します。
ヘルスプローブを追加して、EDB PgBouncerインスタンスが仮想マシンで利用可能かどうかを確認します。プロトコルとしてTCP を選択し、ポートとして6432 を選択します。
ポート6432 の負荷分散ルールを追加します。このルールにより、そのポートに向かうネットワークトラフィックが、バックエンドプールに存在するすべての仮想マシンに均等に分散されます。タイプとしてPublic ロードバランサーまたはInternal ロードバランサーを選択します。

これらの構成を完了した後、ポート6432を使用して、ネットワークロードバランサーのIPアドレスでデータベースに接続できます。プライマリデータベースサーバーで障害が発生すると、フェールオーバーマネージャーは新しいプライマリを昇格し、EDB PgBouncerを再構成してトラフィックを再分散します。 EDB PgBouncerプロセスのいずれかがトラフィックを受け入れることができない場合、ネットワークロードバランサーはすべてのトラフィックを残りのEDB PgBouncerプロセスに再分散します。 max_client_conn パラメーターが、フェイルオーバーの場合に多数の接続を補償するように調整されていることを確認してください。

AWSでNLBを設定する¶

次のサンプル構成では、次のことを前提としています。

すべてのEC2インスタンスとロードバランサーが同じサブネットにデプロイされます。必要に応じて、データベースノードを別のサブネットに追加できますが、これにはより複雑な構成が必要であり、パフォーマンスに影響を与える可能性があります。
PgBouncerのセキュリティグループとデータベースインスタンスのセキュリティグループがあります。