Other considerations

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

データの一貫性

CRDTデータ型を使用した列の競合の処理 について読んで、データの一貫性の観点からの非同期操作モードの影響を理解してください。

展開

PGDは、 信頼できるPostgresアーキテクト またはテクニカルサポートによって承認された構成管理アプローチと展開アーキテクチャのいずれかを使用して、少数の既知の良好な構成の1つで展開されることを目的としています。

手動展開はお勧めできず、サポートされていない場合があります。

ログメッセージとドキュメントは現在、英語でのみ提供されています。

サイジングの考慮事項

本番デプロイメントの場合、EDBは、Postgresデータノードごとに最小4コアをお勧めします。 Witnessノードはデータレプリケーションオペレーションに参加しないため、この要件を満たす必要はありません。サブグループRaftなしで1つのコアで十分です。サブグループRaftを使用する場合、2つのコアで十分です。ノード昇格の場合のパフォーマンスの低下を回避するために、ロジカルスタンバイのサイズは常にデータノードとまったく同じにしてください。運用展開では、PGDプロキシノードには少なくとも1つのコアが必要であり、データベースコアの数を約1:10の比率で増加させながら段階的に増やす必要があります。特定のパフォーマンス要件の詳細なベンチマークを行って、ワークロードに基づいて適切なサイジングを決定することをお勧めします。必要に応じて、EDBプロフェッショナルサービスチームが支援します。

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

Postgresデータノード、 Barmanノード、およびPGD Proxyノードを仮想マシンに、またはベアメタル展開モードで展開できます。ただし、復元性が低下するため、同じ物理ハードウェア上にあるVMに複数のデータノードを展開しないでください。また、同じ物理ハードウェア上のVMに複数のPGDプロキシノードを展開しないでください。これも、復元性が低下するためです。

単一のPGDプロキシノードは、単一のPGDデータノードと同じ場所に配置できます。

時計とタイムゾーン

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

NTPまたはその他のソリューションを使用して、サーバーのクロックを同期します。

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

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

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