★PostgreSQLカンファレンス2024 12月6日開催/チケット販売中★
他のバージョンの文書 16 | 15 | 14 | 13 | 12 | 11 | 10 | 9.6 | 9.5 | 9.4 | 9.3 | 9.2 | 9.1 | 9.0 | 8.4 | 8.3 | 8.2 | 8.1 | 8.0 | 7.4 | 7.3 | 7.2

第27章 高可用性、負荷分散およびレプリケーション

目次

27.1. 様々な解法の比較
27.2. ログシッピングスタンバイサーバ
27.2.1. 計画
27.2.2. スタンバイサーバの動作
27.2.3. スタンバイサーバのためのプライマリの準備
27.2.4. スタンバイサーバの設定
27.2.5. ストリーミングレプリケーション
27.2.6. レプリケーションスロット
27.2.7. カスケードレプリケーション
27.2.8. 同期レプリケーション
27.2.9. スタンバイにおける継続的アーカイビング
27.3. フェイルオーバー
27.4. ホットスタンバイ
27.4.1. ユーザのための概説
27.4.2. 問い合わせコンフリクトの処理
27.4.3. 管理者のための概説
27.4.4. ホットスタンバイパラメータリファレンス
27.4.5. 警告

データベースサーバは共同して稼働できます。 その目的は、最初のサーバが故障したとき次のサーバへ速やかに引き継ぎができること(高可用性)および複数のコンピュータが同一のデータを処理できること(負荷分散)です。 データベースサーバがシームレスに共同稼働できれば理想的です。 静的なウェブページを提供するウェブサーバは、ウェブからの要求で生ずる負荷を複数のマシンに分散するだけで、簡単に結合できます。 実際、読み取り専用のデータベースサーバの結合は、同じようにかなり容易です。 しかし、大部分のデータベースサーバは、読み書きの混在した要求を受け取り、読み書き両用のサーバの結合はとても困難です。 なぜなら、読み取り要求だけの場合、全サーバへのデータの配布は1回で終わります。 しかし、書き込み後の読み取り要求に対して一貫性のある結果を返すためには、書き込み要求を受けたサーバだけでなく、他の全サーバにおいてもデータに書き込まなければなりません。

この同時性を持たせるという問題は、共同して稼働するサーバにおいて根本的に困難なものです。 すべての使用状況において、単一の解法を用いて同時性の問題の影響を軽減できないため、複数の解法が存在します。 各々の解法はこの問題に異なったやり方を適用し、固有の作業負荷に対する影響を最小化します。

幾つかの解法では、1つのサーバだけにデータの更新を許可することにより、同時性を持たせています。 データの更新ができるサーバを、読み書きサーバ、マスタサーバまたはプライマリサーバといいます。 プライマリの変更を追跡するサーバを、スタンバイサーバまたはセカンダリサーバといいます。 プライマリサーバに昇格するまで接続できないスタンバイサーバをウォームスタンバイサーバといいます。 接続を受理できて読み取り専用の問い合わせを処理できるスタンバイサーバをホットスタンバイサーバといいます。

いくつかの同期の解法が提供されています。 すなわち、データに書き込むトランザクションでは、全サーバがコミットするまでトランザクションはコミットされません。 これによって、フェイルオーバーにおいてデータの消失がないことが保証されます。 また、どのサーバが問い合わせを受理したかに関係なく、全ての負荷分散サーバが一貫した結果を返すことが保証されます。 それに対して非同期の解法では、コミット時刻と他サーバへの伝達時刻に時間差がありうるため、バックアップサーバへ交代する時にトランザクションが消失する可能性があります。 また、負荷分散サーバにおいては、最新でない結果を応答する可能性があります。 サーバ間の非同期の通信は、同期が非常に低速な場合に使用されます。

解法は粒度によって分類することもできます。 ある解法ではデータベースサーバ全体だけを範囲として処理しますが、他の解法では各テーブルまたは各データベースを範囲として管理できます。

すべての選択において、作業効率を考えなければなりません。 通常、作業効率と機能性は相反する関係にあります。 例えば、遅いネットワークの場合、完全同期の解法を使えば作業効率は半分以下となりますが、非同期の解法を使えば作業効率への影響が最小となります。

本節では、フェイルオーバーとレプリケーションと負荷分散における種々の解法を説明します。