Other considerations ==================== 展開を計画するときは、これらのその他の考慮事項を確認してください。 データの一貫性 -------------- :ref:`競合 <競合>` について読んで、データの一貫性の観点からの非同期オペレーションモードの影響を理解します。 展開 ---- PGDは、:ref:`Trusted Postgres ArchitectTPAのインストール ` またはテクニカルサポートによって承認された構成管理アプローチと展開アーキテクチャを使用して、少数の既知の正常な構成のいずれかで展開することを目的としています。 手動展開は推奨されず、サポートされていない場合があります。 ログメッセージとドキュメントは、現在英語でのみ利用できます。 サイズ設定の考慮事項 -------------------- 運用展開の場合、EDBは、Postgresデータノードごとに少なくとも4コアを推奨します。 Witnessノードはデータレプリケーション操作に参加せず、この要件を満たす必要はありません。サブグループRaftなしで1つのコアで十分です。サブグループRaftを使用する場合、2つのコアで十分です。ノードが昇格した場合のパフォーマンスの低下を回避するために、常にデータノードとまったく同じようにロジカルスタンバイのサイズを設定します。運用展開では、 PGDプロキシノードには少なくとも1コアが必要で、データベースコア数の増加に応じて約1:10の比率で段階的に増やす必要があります。特定のパフォーマンス要件の詳細なベンチマークを作成して、ワークロードに基づいて適切なサイジングを決定することをお勧めします。 EDBプロフェッショナルサービスチームが、必要に応じてサポートします。 開発のために、2コア未満のPostgresデータノードを割り当てないでください。 Barmanノードのサイズは、データベースのサイズとデータ変更率によって異なります。 Postgresデータノード、 Barmanノード、およびPGDプロキシノードを仮想マシンまたはベアメタル展開モードで展開できます。ただし、復元性が低下するため、同じ物理ハードウェア上にあるVMに複数のデータノードを展開しないでください。また、同じ物理ハードウェア上のVMに複数のPGDプロキシノードを展開しないでください。それも復元性が低下します。 単一のPGDプロキシノードは、単一のPGDデータノードとコロケーションできます。 時計とタイムゾーン ------------------ EDB Postgres分散は、マルチプルのタイムゾーンのノードで動作するように設計されており、真にワールドワイドなデータベースクラスターを実現します。個々のサーバーは一致するタイムゾーンで構成する必要はありませんが、 ``log_timezone = UTC`` を使用して、人間が判読可能なサーバーログにアクセスしやすく比較しやすくすることをお勧めします。 NTPまたはその他のソリューションを使用してサーバークロックを同期します。 他の一部のソリューションの場合と同様、クロック同期はパフォーマンスにとって重要ではありません。クロックスキューはオリジンの競合検出に影響を与える可能性がありますが、 EDB Postgres Distributedは、存在するスキューを報告および管理する制御を提供します。 EDB Postgres Distributedは :ref:`Column-level conflict detection ` で説明しているように、行バージョンの競合検出も提供します。