以下は、無料でダウンロードできるホワイトペーパー「PostgreSQL Management andAutomationwithClusterControl」からの抜粋です。
改訂注：このブログのマスタースレーブで使用されている用語は、PostgreSQLで使用されているマスタースタンバイの用語と同義であることに注意してください。他のテクノロジーとの並列性を維持するために、マスタースレーブを使用しています。
HA構成の場合、複数のアーキテクチャを使用できますが、基本的なアーキテクチャはマスタースレーブアーキテクチャとマスターマスターアーキテクチャです。データベースサーバーは連携して、プライマリサーバーに障害が発生した場合に2番目のサーバーが迅速に引き継ぐことができます（高可用性）、または複数のコンピューターが同じデータを提供できるようにする（負荷分散）。
PostgreSQLマスタースレーブアーキテクチャ
これらのアーキテクチャにより、プライマリサーバーに障害が発生した場合に操作を引き継ぐ準備ができている1つ以上のスタンバイサーバーを備えたマスターデータベースを維持できます。これらのスタンバイデータベースは、マスターと同期されたままになります（またはほぼ同期されます）。
マスターとスレーブ間のレプリケーションは、SQLステートメント（論理スタンバイ）または内部データ構造の変更（物理スタンバイ）を介して行うことができます。 PostgreSQLは、先行書き込みログ（WAL）レコードのストリームを使用して、スタンバイデータベースの同期を維持します。メインサーバーに障害が発生した場合、スタンバイにはメインサーバーのほぼすべてのデータが含まれ、すぐに新しいマスターデータベースサーバーにすることができます。これは同期または非同期にすることができ、データベースサーバー全体に対してのみ実行できます。
ストリーミングレプリケーションの設定は、いくつかの手順を完全に実行する必要があるタスクです。これらの手順とこのテーマに関するその他の背景については、「PostgreSQLDBAになる-高可用性のためにストリーミングレプリケーションを設定する方法」を参照してください。
バージョン10以降、PostgreSQLには論理レプリケーションを設定するオプションが含まれています。
論理レプリケーションにより、データベースサーバーはデータ変更のストリームを別のサーバーに送信できます。 PostgreSQL論理レプリケーションは、WALから論理データ変更のストリームを構築します。論理レプリケーションを使用すると、個々のテーブルからのデータ変更をレプリケートできます。特定のサーバーをマスターまたはレプリカとして指定する必要はありませんが、データを複数の方向に流すことができます。
論理レプリケーションの詳細については、ブログ：PostgreSQLでの論理レプリケーションの概要をご覧ください。
高可用性を効果的に確保するには、マスタースレーブアーキテクチャを用意するだけでは不十分です。また、何らかの自動形式のフェイルオーバーを有効にする必要があるため、何かが失敗した場合でも、通常の機能を再開する際の遅延を最小限に抑えることができます。 PostgreSQLには、マスターデータベースの障害を識別し、所有権を取得するようにsalveに通知する自動フェイルオーバーメカニズムが含まれていないため、DBA側で少し作業が必要になります。スレーブを新しいマスターとしてプロモートするpg_ctlpromoteコマンドを含むスクリプトで作業する必要があります。この自動化のためのサードパーティツールもいくつかあります。このようなツールは数多く存在し、IPアドレスの移行など、フェイルオーバーを成功させるために必要なオペレーティングシステム機能と十分に統合されています。
フェイルオーバーが発生した後、新しいマスターで動作するように、それに応じてアプリケーションを変更する必要があります。また、サーバーは1つしか機能しないため、マスタースレーブアーキテクチャを再作成する必要があります。これにより、問題が発生する前と同じ通常の状況に戻ります。
今日のホワイトペーパーをダウンロードするClusterControlを使用したPostgreSQLの管理と自動化PostgreSQLの導入、監視、管理、スケーリングを行うために知っておくべきことについて学ぶホワイトペーパーをダウンロードするPostgreSQLマスター-マスターアーキテクチャ
このアーキテクチャは、一方のノードでエラーの影響を最小限に抑える方法を提供します。もう一方のノードがすべてのトラフィックを処理できるため、パフォーマンスにわずかな影響を与える可能性がありますが、機能が失われることはありません。また、サーバーにリソースを追加する（スケールアップ）垂直スケーラビリティの概念とは反対に、水平スケーラビリティ（スケールアウト）を実現するためにも使用されます（おそらくこれはさらに興味深い点です）。
このアーキテクチャは（まだ）PostgreSQLでネイティブにサポートされていないため、このアーキテクチャを実装するには、外部ツールを使用する必要があります。
マスターマスターを実装するためのソリューションを選択するときは、さまざまな製品があるため、十分に注意する必要があります。それらの多くはまだ「グリーン」であり、深刻なユーザーや成功事例はほとんどありません。一方、他のいくつかのプロジェクトは、アクティブなメンテナがいないために放棄されました。
利用可能なツールの詳細については、ブログ：PostgreSQL用のトップPGクラスタリングHAソリューションを参照してください。
負荷分散と接続プール
アプリケーションからのトラフィックを管理してデータベースアーキテクチャを最大限に活用するために使用できるロードバランサーツールがいくつかあります。同様に、これらの接続をプールして異なるリクエスト間で再利用することにより、アプリケーションがデータベースに接続する方法を管理するのに役立つ他のいくつかの接続があります。
よく知られているpgpoolのように、両方の目的で使用される製品もあれば、pgbouncer（接続プール）やHAProxy（負荷分散に使用される）のように、これらの機能の1つだけに焦点を当てる製品もあります。