Node restart and down node recovery =================================== PGDは、ノードの再起動またはノードの切断から復旧するように設計されています。切断されたノードは、各ピアノードに再接続し、そのノードから欠落しているデータを複製することにより、グループに再参加します。 ノードが起動すると、各接続は\ ``bdr.node_slots.state = catchup`` を使用して :ref:`bdr.node_slots ` に表示され始め、欠落データの複製を開始します。キャッチアップは、各ピアノードからの欠落データの量に応じて継続され、サーバーのワークロードに応じて、時間の経過とともに増加する可能性があります。 各ノードの書き込みアクティビティの量が均一でない場合、より多くのデータを持つノードからのキャッチアップ期間は他のノードよりも大幅に長くかかる場合があります。最終的に、スロットの状態は\ ``bdr.node_slots.state = streaming`` に変更されます。 時間や日などの長期間オフラインになっているノードは、さまざまな理由でリソースの問題を発生させる可能性があります。次の問題を理解することなく、長期の停止を計画しないでください。 各ノードは変更情報を保持します1つの `replication slot `_ を使用 ピアノードごとに)したがって、後で一時的に到達不能なノードへの変更を再生できます。ピアノードが無期限にオフラインになったままである場合、この蓄積された変更情報により、最終的にノードはPostgreSQLトランザクションログ\ ``pg_wal`` の *WAL* 用の記憶領域が不足し、これに似たエラーでデータベースサーバーがシャットダウンする可能性があります。 :: PANIC: could not write to file "pg_wal/xlogtemp.559": No space left on device または、他のディスク不足関連の症状を報告する場合があります。 さらに、オフラインノードのスロットもカタログxminを抑制し、カタログテーブルのバキュームを防止します。 EDB Postgres Extended ServerおよびEDB Postgres Advanced Serverでは、オフラインノードもデータのフリーズを抑制して、競合解決データの損失を防ぎます :ref:`オリジンの競合検出 <オリジンの競合検出>` を参照してください。 管理者は、ノードの停止を監視し :ref:`競合のモニタリング <競合のモニタリング>` を参照して、ノードに十分な空きディスク領域があることを確認する必要があります。ワークロードが予測可能な場合は、時間の経過とともに使用される領域の量を計算できるため、重要な問題が発生する前にノードがダウンできる最大時間を予測できます。 PGDによって作成されたレプリケーションスロットを手動で削除しないでください。そうした場合、クラスターは損傷し、 :ref:`Replication slots created by PGD ` で説明しているように、スロットを使用していたノードをクラスターから分離する必要があります。 ノードがオフラインである間、他のノードはオフラインノードから同じデータのセットをまだ受け取っていない可能性があるため、これはノード全体でのわずかな相違として現れる場合があります。分離プロセスは、ノード間のこの不均衡を修正します。後のバージョンではこれを早く行う場合があります。