データベースのコピーを 1つだけ保有すればよいため、共有ディスクを用いたフェイルオーバーは同期によるオーバーヘッドを回避できます。 本解法では、複数のサーバが単一のディスクアレイを共有します。 主データベースサーバが故障したとき、まるでデータベースの破損から復旧したように、スタンバイサーバが元のデータベースを実装して稼働できます。 これはデータの消失がない高速なフェイルオーバーを行うことができます。

ハードウェアを共有するという機能は、ネットワーク上の記憶装置では一般的です。 ネットワークファイルシステムの利用も可能ですが、そのファイルシステムがPOSIX仕様を満たしているか注意してください。 （ 19.2.2.1を見てください）。 本解法には重大な制約があり、共有ディスクアレイが故障または破損したとき、プライマリサーバもスタンバイサーバも機能しなくなります。 また、プライマリサーバが稼働している間は、スタンバイサーバが共有記憶装置にアクセスしてはなりません。

ハードウェア共有機能の改善の一つとしてファイルシステムのレプリケーションをあげることができます。 それは、あるファイルシステムに対して行われたすべての変更を他のコンピュータに存在するファイルシステムにミラーリングします。 制約はただ一つであり、スタンバイサーバがファイルシステムの一貫したコピーを自身の領域に持つようにミラーリングしなければなりません。具体的には、スタンバイサーバへの書き込みがプライマリサーバへの書き込みと同じ順序でおこなわれなければなりません。 LinuxにおけるDRBDは、ファイルシステムレプリケーションで広く受けいれられている手法です。

ウォームスタンバイおよびホットスタンバイサーバは、ログ先行書き込み（WAL）のレコードを解読して最新の状態を保持できます。 プライマリサーバが故障したとき、スタンバイサーバがプライマリサーバのほぼすべてのデータを保存して、速やかに新しいプライマリデータベースサーバを作成できます。 本解法は同期、非同期で行うことができ、データベース全体だけを範囲として処理できます。

スタンバイサーバは、ファイル単位のログシッピング（27.2参照）またはストリーミングレプリケーション（27.2.5参照）または両者の併用を使用して実装できます。 ホットスタンバイの情報は 27.4 を参照してください。

論理レプリケーションにより、データベースサーバが他のサーバに、データ更新のストリームを送ることができます。 PostgreSQLの論理レプリケーションは、WALから論理的なデータ更新のストリームを構築します。 論理レプリケーションでは、テーブル単位でデータ変更をレプリケーションすることができます。 さらに自分の変更をパブリッシュしているサーバは同時に他のサーバから変更をサブスクライブできるので、複数の方向にデータを流すことができます。 論理レプリケーションの更なる情報については、第31章をご覧ください。 なお、ロジカルデコーディングインタフェース(第49章)を使って、サードパーティ拡張は同様の機能を提供できます。

トリガベースのレプリケーションの構成では、通常はデータを変更する問い合わせを指定されたプライマリサーバに送り込みます。 テーブル単位で処理を行い、プライマリサーバはデータの変更を（典型的には）非同期でスタンバイサーバに送信します。 スタンバイサーバは、プライマリが処理中に問い合わせに応答し、ローカルでのデータ変更あるいは書き込み処理を行うことができます。 この形式のレプリケーションは、大量のデータ分析の負荷軽減や、データウェアハウスの問い合わせにしばしば利用されます。

この種類のレプリケーションの一例はSlony-Iであり、テーブル単位の粒度を持ち、複数のスタンバイサーバが稼働できます。 （バッチ処理によって）スタンバイサーバのデータを非同期で更新するため、フェイルオーバーにおけるデータ消失の可能性があります。

SQLに基づいたレプリケーションのミドルウェアでは、プログラムがすべてのSQL問い合わせを採取して、1つまたはすべてのサーバに送付します。 なお、各々のサーバは独立して稼働します。 読み書き問い合わせは、すべてのサーバがすべての変更を受け取るように全サーバに送付されなければなりません。 しかし、読み取り専用の問い合わせはサーバ全体の読み取り負荷を分散させるために、1つのサーバだけに送付することができます。

問い合わせを修正しないで送付した場合、random()関数による乱数値とCURRENT_TIMESTAMP関数による現在時刻およびシーケンス値が、サーバごとに異なることがあります。 その理由は、各サーバが独立して稼働しているため、および、実際のデータ変更ではなくSQL問い合わせが送信されるからです。 これが許容できない場合は、ミドルウェアかアプリケーションで単一のソースからそのような値を確定し、その結果を書き込み問い合わせで使用しなければなりません。 トランザクションをコミットするか中断するかについても、全サーバが同一となるよう注意しなければなりません。 これには2相コミット（PREPARE TRANSACTIONおよびCOMMIT PREPARED）を使用することになるでしょう。 Pgpool-IIとContinuent Tungstenがこのレプリケーションの一例です。

ラップトップやリモートマシンのように、通常は接続されていない、あるいは遅い通信リンクで接続されているサーバ間において、データの一貫性を保持することは挑戦的な課題です。 非同期マルチマスタレプリケーションの使用により、全サーバの独立した稼働、およびトランザクションの衝突を識別するための定期的な通信を実現します。 トランザクションの衝突は、利用者および衝突回避法によって解決できるでしょう。 Bucardoはこの種のレプリケーションの一例です。

同期マルチマスタレプリケーションでは全てのサーバが書き込み要求を受理できます。 受理したサーバは更新したデータを、トランザクションをコミットする前に、他の全サーバへ配布します。 書き込み負荷が重いとき、ロックの掛かり過ぎやコミットの遅延による作業効率の低下の原因となりえます。 読み取り要求はどのサーバにも送付できます。 通信による負荷を減らすには、共有ディスクが実装されます。 同期マルチマスタレプリケーションは、主に読み取り作業負荷の低減に最適ですが、全てのサーバが書き込み要求を受理できることも大きな利点です。 その利点とは、プライマリとスタンバイ間で作業負荷を分けなくてよいこと、および更新データが1つのサーバから他のサーバに送付されるため、出力が確定しないrandom()関数などによる問題が起こらないことです。

PostgreSQL では、この種類のレプリケーションを提供しません。 しかし、PostgreSQL の 2相コミット（PREPARE TRANSACTIONおよびCOMMIT PREPARED）を使用すれば、アプリケーションのコードまたはミドルウェアにおいて本解法を実装できます。

データの分割とは、同じテーブルのデータを複数部分に分けることです。 各部分に書き込むことができるのは、1つのサーバだけです。 例えば、データをロンドンとパリの営業所用に分割でき、サーバをロンドンとパリのどちらにも設置できた状態を考えます。 問い合わせにロンドンとパリのデータが混在した場合、アプリケーションは両方のサーバに問い合わせることができます。 または、プライマリ／スタンバイレプリケーションを使用して、他の営業所のデータを読み取り専用コピーとして保持できます。

上述した多くの解法は、複数のサーバが複数の問い合わせを処理するものです。 処理速度の向上のために、単一の問い合わせに複数のサーバを使用するものはありません。 本解法は複数のサーバが単一の問い合わせを共同して実行するものです。 その方法は、データをサーバ間で分割し、各サーバが部分的に問い合わせを実行し、各々の結果をプライマリサーバに送付し、プライマリサーバが合体して利用者に返送するものです。 これはPL/Proxyツールセットを使用して実装できます。