postgresqlの高可用性

PostgreSQLデータベースは初めてです。最近、開発者はシステムでいくつかのアップグレードを行う必要がありました。

そのため、データベースのフェイルオーバーを実装するために、いくつかの方法を実装することを計画しています。

ここの postgresql wikiからの私の読書に基づいて、私たちはウォームスタンバイまたはホットスタンバイのいずれかを実装しようとしています。だから私の質問は：

1. それらの主な違いは何ですか？
2. どっちがいいですか？
3. Postgresデータベースで高可用性を実現するために検討できる他の方法はありますか？

1a。ウォームスタンバイは「ライブ」の増分バックアップで、それぞれ16 mbの変更の完全なブロック（ウォールセグメント）が供給され、データがいっぱいになるとスタンバイノードに送信されます。ウォームスタンバイノードを照会することはできません。16 mbの変更（デフォルト）は、多くのトランザクションを意味する可能性があり、マスターが失敗した場合、それらは失われます。

1b。ホットスタンバイ。（これも「ライブ」増分バックアップ）.small変更がスレーブに送信されます（walレコードは、walセグメントの小さな部分です）。ホットスタンバイノードを照会（読み取り専用）できます。マスターが失敗した場合にトランザクションが失われる時間はごくわずかです。同期と非同期のホットスタンバイノードがあり、同期ノードはマスターが変更の適用を確認するのを待機するように強制し、その後マスターはトランザクションをコミットします。非同期レプリケーションでは、マスターはwalレコードを送信し、確認を待機しません。前者は、マスターとスレーブ間に非常に信頼性が高く高速なリンクを必要とし、マスターにオーバーヘッドを追加しますが、データ損失を保証しません。

増分バックアップについて：1.データベース全体のベースコピーを作成します。2.スレーブに発送します。3.変更に追いつくように構成します。

ここではストリーミングレプリケーション（ホットスタンバイ）が最適です。マスターにかなりの負担をかけず、レプリケーションラグが非常に小さい（多くの場合数秒）ので、私は個人的に非同期レプリケーションを好みます。

このセットアップを補完する1つはpg-poolです。これは、前述のようなレプリケーション構成に参加しているアプリケーションとサーバー間のプロキシとして機能し、ロードバランシングと並列クエリ機能を備えています。また、自動フェイルオーバーを提供することもできます。 http://www.pgpool.net/pgpool-web/contrib_docs/simple_sr_setting/index.html

あなたがすでに得た答えは役に立ちますが、ここで少し混乱する用語です。すべての組み込みレプリケーションソリューションは、同じ基本メカニズムを使用します。つまり、先行書き込みログデータをスタンバイサーバーにコピーします。

レプリケーション用のWALデータは、archive_command機能を使用するか、ストリーミングレプリケーション（SR）を使用して、一度に16MBのファイルに移動できます。SRを使用する場合は、実際にアーカイブもセットアップする必要があり、サーバーはそれらを適切に切り替えます。

クエリに応答できないウォームスタンバイサーバーを使用できます。または、読み取り専用サーバーに応答できるホットスタンバイサーバーを使用することもできます。これは、データがスタンバイに送られる方法とは無関係です。

これら2つの選択肢はそれぞれ他の選択肢と組み合わされ、4つすべての組み合わせを持つことができます。一度にファイルをWALセグメントに供給しながら、ホットスタンバイ応答クエリを実行できます。ホットスタンバイが有効になっていないストリーミングレプリケーションサーバーを使用できるため、クエリに応答しません。現在、最も一般的なケースは、ストリーミングレプリケーションとホットスタンバイの両方です。これが完全な機能セットです。繰り返しになりますが、今は回避できるという理由だけで、古いarchive_commandメカニズムを無視しないでください。それでも、他の方法では回復するのが難しいストリーミング障害からあなたを救うことができます。