Failover Manager with EDB PgBouncer

Failover Manager with EDB PgBouncer#

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

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

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

クラウドでのEDB PgBouncerを使用したフェールオーバーマネージャー#

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

Failover Manager with PgBouncer cloud architecture diagram

Failover Manager with PgBouncer cloud architecture diagram#

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

  • クラウドネットワークロードバランサーの制限 Azure

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

  • 混合アーキテクチャでは、EDB PgBouncerとPostgres間のトラフィックがアンバランスになる場合がありますローカル、場合によってはネットワーク。

  • EDB PgBouncerとPostgreSQLがリソースをめぐって競合します。

  • これらの2つのコンポーネントが同じマシンで組み合わせられている場合、マスター障害はルーティングEDB PgBouncerとデータベースの両方に影響を与えます。

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

インストール#

次のようにAWS仮想マシンにAdvanced Serverデータベース、フェールオーバーマネージャー、およびEDB PgBouncerをインストールおよび構成します。

Systems

Components

PgDB srv 1, 2, 3

Primary / standby node running Advanced Server and Failover Manager

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-5.<x>/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

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

script.load.balancer.attach=/usr/edb/efm-5.<x>/bin/efm_pgbouncer_functions attach %h %t <pgbs1>,<pgbs2>

<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

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

listen_addr = *

  1. 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

  1. データベース章を再構成し、pgbouncerをリロードするために使用するスクリプト/usr/edb/pgbouncer1.15/bin/redirect.sh を作成します。スクリプトの所有者がルートであり、そのユーザー/グループ/その他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 が有効になっていることを確認します。次のコマンドで確認できます。

grep ^PasswordAuthentication /etc/ssh/sshd_config

yes に設定されていることを確認します。必要に応じて、変更してssh をリスタートします。

フェールオーバーマネージャー/PostgreSQLホストでの構成#

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

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

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

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

ssh-copy-id enterprisedb@<pgbouncerhost>

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ユーザーの一時パスワードをリセットできます。

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が使用するセキュリティグループのルール

タイプ |プロトコル | ポートレンジ | ソース | 説明 ————|—————|—————-|— ————-|——————- カスタムTCP | TCP | 7800 |サブネット全体 |フェールオーバーマネージャーカスタムTCP | TCP | 5444 |サブネット全体|PostgresカスタムTCP| TCP | 22 |サブネット全体 | 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のセキュリティグループとデータベースインスタンスのセキュリティグループがあります。

Creating rules for security groups で説明されているルールを構成した後、AWSドキュメントに従ってください

  • 次の詳細を使用してターゲットグループを作成します。

名前 |タイプ |プロトコル | ポート | VPC —————|————–|————– |—————-|—————————- ——————— pgbouncer |インスタンス | TCP | 6432 | インスタンスが接続されているVPCを選択します。

残りの設定 ヘルスチェックTCP および Advanced health check 設定)はデフォルトのままにします。

作成したターゲットグループをEDB PgBouncerを実行しているインスタンスに登録します。

  • 次の詳細を使用してロードバランサーを作成します。

タイプ | VPC |リスナー | ————————————————– ———————|—————————- ——————-|—————————- ————————————————– ——-| Public またはInternal 。 EDBは、内部ロードバランサーを使用することをお勧めします。| VPCを選択し、目的のゾーンにマッピングします。 | 6432 としてTCP を使用してリスナーを作成し、ターゲットグループpgbouncerに転送します。 |

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

目次