PostgreSQL 高可用性
PostgreSQL 10 は、読み取りまたは書き込みリクエストを受信したときに各ノードが最新の状態になるように、すべてのノード間でそのデータを同期化しなければなりません。潜在的な同期化の問題を解決するソリューションは 1 つだけではないので、考慮すべき HA のオプションが多数あります。PostgreSQL 10 での HA ソリューションの比較が表形式で
https://www.postgresql.org/docs/10/different-replication-solutions.html に示されています。
以下の図に、PTC が推奨する PostgreSQL HA 展開のコンフィギュレーションを示します。
PostgreSQL
ThingWorx は大量のコンテンツをそのデータベースに書き込むことができ、すべての PostgreSQL ノードで書き込みシーケンスはそのまま維持することが重要です。同期レプリケーションに設けられている制限の範囲内で、カスケードレプリケーションアーキテクチャ内の同期レプリケーション用にすべての PostgreSQL ノードを設定することをお勧めします。このオプションには以下の要件があります。
• 3 つの同じサイズの PostgreSQL サーバーノードを展開しなければなりません。
◦ 1 つのノードはマスターになり、書き込みリクエストが転送されます。マスターは WAL レコードをスタンバイノードにストリーミングし、スタンバイノードが確認した場合にのみトランザクションをコミットします。
◦ 1 つのスタンバイノードはマスターからのストリーミングコンテンツを受信します。さらに、そのコンテンツを 2 つ目のスタンバイノードにストリーミングします。
◦ もう 1 つのスタンバイノードは 1 つ目のスタンバイノードからのストリーミングコンテンツを受信します。ノードが失敗した場合やいずれかのノードがオフラインになった場合、このノードが残り 2 つのうちの 1 つになり、マスター-スタンバイ確認ストリーミングプロセスを続けて完了します。
Pgpool-II
PostgreSQL HA コンフィギュレーションを実現するには、書き込み/読み取りリクエストを適切なノードに転送し、ノードの正常性を監視し、正常でないノードをオフラインにして修復しなければなりません。これらのタスクを実行するには Pgpool-II が推奨されます。このオプションには以下の要件があります。
• 2 つの同じサイズの Pgpool サーバーノードを展開しなければなりません。これらはアクティブ/パッシブモードで動作します。
◦ 1 つのノードはマスターとして動作します。これは PostgreSQL マスターノードに書き込みトラフィックを転送し、PostgreSQL スタンバイノードに読み取りトラフィックを転送します。
◦ 1 つのノードはスタンバイとして動作します。これは Pgpool マスターノードが失敗したときにトラフィックの分散を引き継ぎます。
• 1 つの仮想 IP アドレスがこれらの Pgpool-II ノードによって管理されます。マスターはこのアドレスを使用してクライアントからの PostgreSQL トラフィックを受信します。
Pgpool-II に関する注記:
• Windows 環境では Pgpool-II はサポートされていません。
• クラウド実装の PostgreSQL では、Pgpool-II の代わりに直接 DNS フェイルオーバーメカニズムが使用されることがあります。
• ThingWorx アプリケーションと同じサーバー上で Pgpool-II プロセスを実行することで、HA 環境でのサーバーの総数を削減できます。
• PostgreSQL レプリケーションの管理に Pgpool-II を使用することは推奨されていません。このドキュメントで示されているガイダンスでは、PostgreSQL のストリーミングレプリケーションが使用され、トラフィックのルーティング、ノード正常性の監視、フェールオーバーの自動化には Pgpool-II が使用されています。