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

目次

26.1. 様々な解法の比較
26.2. ログシッピングスタンバイサーバ
26.2.1. 計画
26.2.2. スタンバイサーバの動作
26.2.3. スタンバイサーバのためのマスタの準備
26.2.4. スタンバイサーバの設定
26.2.5. ストリーミングレプリケーション
26.2.6. レプリケーションスロット
26.2.7. カスケードレプリケーション
26.2.8. 同期レプリケーション
26.2.9. スタンバイにおける継続的アーカイビング
26.3. フェールオーバ
26.4. この他のログシッピングの方法
26.4.1. 実装
26.4.2. レコードベースのログシッピング
26.5. ホットスタンバイ
26.5.1. ユーザのための概説
26.5.2. 問い合わせコンフリクトの処理
26.5.3. 管理者のための概説
26.5.4. ホットスタンバイパラメータリファレンス
26.5.5. 警告
<title>High Availability, Load Balancing, and Replication</title> <indexterm><primary>high availability</></> <indexterm><primary>failover</></> <indexterm><primary>replication</></> <indexterm><primary>load balancing</></> <indexterm><primary>clustering</></> <indexterm><primary>data partitioning</></>

Database servers can work together to allow a second server to take over quickly if the primary server fails (high availability), or to allow several computers to serve the same data (load balancing). Ideally, database servers could work together seamlessly. Web servers serving static web pages can be combined quite easily by merely load-balancing web requests to multiple machines. In fact, read-only database servers can be combined relatively easily too. Unfortunately, most database servers have a read/write mix of requests, and read/write servers are much harder to combine. This is because though read-only data needs to be placed on each server only once, a write to any server has to be propagated to all servers so that future read requests to those servers return consistent results. データベースサーバは共同して稼動できます。 その目的は、最初のサーバが故障したとき次のサーバへ速やかに引き継ぎができること(高可用性)および複数のコンピュータが同一のデータを処理できること(負荷分散)です。 データベースサーバがシームレスに共同稼動できれば理想的です。 静的なウェブページを提供するウェブサーバは、ウェブからの要求で生ずる負荷を複数のマシンに分散するだけで、簡単に結合できます。 実際、読み取り専用のデータベースサーバの結合は、同じようにかなり容易です。 しかし、大部分のデータベースサーバは、読み書きの混在した要求を受け取り、読み書き両用のサーバの結合はとても困難です。 なぜなら、読み取り要求だけの場合、全サーバへのデータの配布は1回で終わります。 しかし、書き込み後の読み取り要求に対して一貫性のある結果を返すためには、書き込み要求を受けたサーバだけでなく、他の全サーバにおいてもデータに書き込まなければなりません。

This synchronization problem is the fundamental difficulty for servers working together. Because there is no single solution that eliminates the impact of the sync problem for all use cases, there are multiple solutions. Each solution addresses this problem in a different way, and minimizes its impact for a specific workload. この同時性を持たせるという問題は、共同して稼動するサーバにおいて根本的に困難なものです。 すべての使用状況において、単一の解法を用いて同時性の問題の影響を軽減できないため、複数の解法が存在します。 各々の解法はこの問題に異なったやり方を適用し、固有の作業負荷に対する影響を最小化します。

Some solutions deal with synchronization by allowing only one server to modify the data. Servers that can modify data are called read/write, <firstterm>master</> or <firstterm>primary</> servers. Servers that track changes in the master are called <firstterm>standby</> or <firstterm>slave</> servers. A standby server that cannot be connected to until it is promoted to a master server is called a <firstterm>warm standby</> server, and one that can accept connections and serves read-only queries is called a <firstterm>hot standby</> server. 幾つかの解法では、1つのサーバだけにデータの更新を許可することにより、同時性を持たせています。 データの更新ができるサーバを、読み書きサーバ、マスタサーバまたはプライマリサーバといいます。 マスタの変更を追跡するサーバを、スタンバイサーバまたはスレーブサーバといいます。 マスタサーバに昇格するまで接続できないスタンバイサーバをウォームスタンバイサーバといいます。 接続を受理できて読み取り専用の問い合わせを処理できるスタンバイサーバをホットスタンバイサーバといいます。

Some solutions are synchronous, meaning that a data-modifying transaction is not considered committed until all servers have committed the transaction. This guarantees that a failover will not lose any data and that all load-balanced servers will return consistent results no matter which server is queried. In contrast, asynchronous solutions allow some delay between the time of a commit and its propagation to the other servers, opening the possibility that some transactions might be lost in the switch to a backup server, and that load balanced servers might return slightly stale results. Asynchronous communication is used when synchronous would be too slow. いくつかの同期の解法が提供されています。 すなわち、データに書き込むトランザクションでは、全サーバがコミットするまでトランザクションはコミットされません。 これによって、フェールオーバにおいてデータの消失がないことが保証されます。 また、どのサーバが問い合わせを受理したかに関係なく、全ての負荷分散サーバが一貫した結果を返すことが保証されます。 それに対して非同期の解法では、コミット時刻と他サーバへの伝達時刻に時間差がありうるため、バックアップサーバへ交代する時にトランザクションが消失する可能性があります。 また、負荷分散サーバにおいては、最新でない結果を応答する可能性があります。 サーバ間の非同期の通信は、同期が非常に低速な場合に使用されます。

Solutions can also be categorized by their granularity. Some solutions can deal only with an entire database server, while others allow control at the per-table or per-database level. 解法は粒度によって分類することもできます。 ある解法ではデータベースサーバ全体だけを範囲として処理しますが、他の解法では各テーブルまたは各データベースを範囲として管理できます。

Performance must be considered in any choice. There is usually a trade-off between functionality and performance. For example, a fully synchronous solution over a slow network might cut performance by more than half, while an asynchronous one might have a minimal performance impact. すべての選択において、作業効率を考えなければなりません。 通常、作業効率と機能性は相反する関係にあります。 例えば、遅いネットワークの場合、完全同期の解法を使えば作業効率は半分以下となりますが、非同期の解法を使えば作業効率への影響が最小となります。

The remainder of this section outlines various failover, replication, and load balancing solutions. A <ulink url="http://www.postgres-r.org/documentation/terms">glossary</ulink> is also available. 本節では、フェールオーバとレプリケーションと負荷分散における種々の解法を説明します。 glossaryも利用できます。