Other considerations

展開を計画するときは、これらの他の考慮事項を確認してください。

展開とサイジングの考慮事項

実稼働デプロイメントの場合、EDBは、各Postgresデータノードと各ロジカルスタンバイに少なくとも12コアをお勧めします。監視ノードはデータレプリケーションオペレーションに参加しないため、この要件を満たす必要はありません。ロジカルスタンバイのサイズは常にデータノードとまったく同じにして、ノードの昇格によるパフォーマンスの低下を回避します。実稼働展開では、 HARPプロキシノードにはそれぞれ少なくとも4つのコアが必要です。 EDBは、EDBのプロフェッショナルサービスチームと協力して、パフォーマンス要件の詳細なベンチマークを行うことをお勧めします。

開発目的では、2コア未満のPostgresデータノードを割り当てないでください。 Barmanノードのサイズは、データベースのサイズとデータ変更率によって異なります。

Postgresデータノード、ロジカルスタンバイ、 Barmanノード、およびHARPプロキシノードを仮想マシンに、またはベアメタル展開モードで展開できます。ただし、データノードとHARPプロキシノード間のアンチアフィニティを維持します。復元性が低下するため、同じ物理ハードウェア上にある VM に複数のデータノードを展開しないでください。また、同じ物理ハードウェア上の VM に複数のHARPプロキシノードを展開しないでください。これも復元性を低下させます。

単一のデータノードを持つ単一のHARPプロキシノードを同じ物理ハードウェアに展開できますが、適切なCPUとメモリのリソース割り当てを保証するためにVMとして展開する必要があります。

時計とタイムゾーン

EDB Postgres Distributedは、マルチプルのタイムゾーンのノードで動作するように設計されているため、真にワールドワイドなデータベースクラスターが可能です。個々のサーバーを一致するタイムゾーンで構成する必要はありませんが、log_timezone = UTCを使用して、人間が読めるサーバーログにアクセスして比較できるようにすることをお勧めします。

サーバーの時計は、NTPまたは他のソリューションを使用して同期する必要があります。

他のソリューションの場合とは異なり、クロックの同期はパフォーマンスにとって重要ではありません。クロックスキューはオリジンの競合検出に影響を与える可能性がありますが、 EDB Postgres Distributedは存在するスキューを報告および管理するコントロールを提供します。

Column-level conflict detection で説明されているように、 EDB Postgres

Distributedは行バージョンの競合検出も提供します。