Release notes for EDB Postgres Distributed version 4.0.1¶
これはBDR 4.0およびHARP 2.0のメンテナンスリリースであり、以前のバージョンで特定された問題の修正と、マイナーな機能強化が含まれています。
Component |
Version |
Type |
Description |
|
|---|---|---|---|---|
BDR |
4.0.1 |
Enhancement |
CAMOパートナーの接続試行の頻度を減らします。 <p>構成を確認し、トランザクションのステータスを確認するためにCAMOパートナーに接続できない場合、すぐに再試行しないでください（完全にビジーなpglogicalマネージャープロセスにつながります）。 1分に1回。</p> |
|
BDR |
4.0.1 |
Enhancement |
LCRセグメントファイルのバッファ読み取りを実装します（BDR-1422）<p>一度に複数のLCRチャンクを読み取れるように、LCRセグメントファイルのバッファリングを実装します。これにより、Decoding Workerを使用する際のWal SendersのI / Oが削減され、CPU使用率が向上します。</p> |
|
BDR |
4.0.1 |
Enhancement |
不要なLCRセグメントの読み取りを回避（BDR-1426） <p> BDRは、少なくとも1つの使用可能な場合に新しいLCRセグメントのみを読み取ろうとします。これにより、Decoding Workerが有効になっているときのI / O負荷が削減されます。</p> |
|
BDR |
4.0.1 |
Enhancement |
結合中の初期COPYを含むCOPYレプリケーションのパフォーマンスが、パーティションテーブルで大幅に改善されました（BDR-1479）<p>大きなテーブルの場合、これによりロード時間が1桁以上改善されます。</p> |
|
BDR |
4.0.1 |
Bug fix |
パラレル適用ワーカーの選択を修正します（BDR-1761）<p>これにより、パラレル適用が再度動作します。 4.0.0では、このバグのため、並列適用は有効になりませんでした。</p> |
|
BDR |
4.0.1 |
Bug fix |
`bdr.camo_pairs`のRaftスナップショットの処理を修正しました（BDR-1753）<p>以前のリリースでは、Raftスナップショットを介して受信したときにCAMOペア構成に変更を正しく伝播しませんでした。</p> |
|
BDR |
4.0.1 |
Bug fix |
アップグレード後にBDR 3.7からRaftスナップショットを正しく処理する（BDR-1754） |
|
BDR |
4.0.1 |
Bug fix |
クラスターのインプレースアップグレードを実行する機能を除外しながら、スナップショットの bdr.camo_pairs を考慮してCAMO構成済みクラスターをアップグレードする（ CAMOとは関係のないアップグレードの制限のため）。 |
|
BDR |
4.0.1 |
Bug fix |
タイムアウト後にのみCAMOからローカルモードに切り替える（RT74892） <p> CAMO保護からローカルモードに切り替えるときに`catchup_interval`推定値を使用しないでください。推定値は、ローカルモードからCAMO保護に戻す場合にのみ使用してください（ CAMOパートナーでの遅延が原因でトグルするのを防ぐため）。</p> |
|
BDR |
4.0.1 |
Bug fix |
パブリッシュされたレプリケーションセットリストが変更されたときのレプリケーションセットキャッシュの無効化を修正しました（BDR-1715）<p>以前のバージョンでは、サブスクリプションが再接続されるまでにパブリッシュする必要があるレプリケーションセット（および結果としてどのテーブル）に関する古い情報を使用できました。< /p> |
|
BDR |
4.0.1 |
Bug fix |
新しいチャンクが使用される場合、同時実行性の高い状況でgallocシーケンスによってローカルに生成される値の重複を防止します（RT76528）<p>新しい値を待っているセッション。これは修正されました。</p> |
|
BDR |
4.0.1 |
Bug fix |
ストリーミングトランザクションでのメモリリークに対処します（BDR-1479）<p> 大規模なトランザクションの場合、ストリーミングトランザクション機能を使用すると、メモリ使用量とI/Oが大幅に削減されます。これにより、主にCOPYレプリケーションのパフォーマンスが向上します。</p> |
|
BDR |
4.0.1 |
Bug fix |
ノードが分離しているときにキャッチアップソースが変更された場合、ノードのPART_CATCHUPフェーズの後にスロットを残さないでください（BDR BDR ）<p>すべてのノードのデータの一貫性を保つために、そのノードから欠落している変更を残りのノード間で転送します。これには、追加のレプリケーションスロットを一時的に作成する必要があります。通常、このレプリケーションスロットはキャッチアップフェーズの最後に削除されますが、変更のソースノードを変更する必要がある特定のシナリオでは、このスロットは以前に取り残されている可能性があります。このバージョンから、このスロットは常に正しく削除されます。</p> |
|
BDR |
4.0.1 |
Bug fix |
BDRグループにノードが1つしかない場合は、グループスロットを前方に移動します<p>これにより、グループが単一のBDRノードだけで実行されたままになった場合のWALの蓄積によるディスクの枯渇を防ぎます。これは推奨される設定ではありませんが、WALの蓄積は意図的なものではありません。</p> |
|
BDR |
4.0.1 |
Bug fix |
BDRグループにノードが1つしかない場合のAdvanced Raftプロトコルバージョン<p>それ以外の場合、シングルノードクラスターは、別のノードが追加されるまで常に最も古いサポートプロトコルを使用します。これにより、その単一のノードで使用可能な機能セットが制限される可能性があります。</p> |
|
HARP |
2.0.1 |
Enhancement |
etcdのようなDCSに依存して異なるロケーションに個別にセットアップするのではなく、ロケーションごとにリーダーを選択するためのサポート。これでも、ロケーションの損失を生き残るために大部分のノードが必要になるため、ロケーションとデータベースノードの両方を奇数にすることをお勧めします。 |
|
HARP |
2.0.1 |
Enhancement |
BDR DCSは、ポーリングノードではなく、コンセンサスからのプッシュ通知を使用するようになりました。この変更により、新しいリーダーの選択にかかる時間が短縮され、 HARPがBDR DCSで実行する負荷が削減されます。 |
|
HARP |
2.0.1 |
Enhancement |
TPAは各HARPプロキシを1つずつ再起動し、戻ってくるまで待機して、ソフトウェアのアップグレード中にアプリケーションで発生したダウンタイムを削減します。 |
|
HARP |
2.0.1 |
Enhancement |
PGBouncerをHARPプロキシに直接埋め込むサポートは非推奨になり、 HARPの次のメジャーリリースで削除されます。 PGBouncerをHARPHARPをポイントするようにTPAを構成できるようになりました。 |
|
HARP |
2.0.1 |
Bug fix |
`harpctl promote <node_name>`は、指定されたノードとは異なるノードを昇格させることがありました。これは修正されました。 [サポートチケット＃75406] |
|
HARP |
2.0.1 |
Bug fix |
分散コンセンサスサービスとしてBDRを使用すると、フェンシングが失敗することがありました。これは修正されました。 |
|
HARP |
2.0.1 |
Bug fix |
`harpctl apply`は、クラスターが確立された後にリーダーのルーティングをオフにしなくなりました。 [サポートチケット＃80790] |
|
HARP |
2.0.1 |
Bug fix |
障害が発生したデータベースを起動できない場合に、Harp-managerが終了しなくなりました。 Harp-managerは、ランダムに増加する期間で再試行し続けます。 [サポートチケット＃78516] |
|
HARP |
2.0.1 |
Bug fix |
内部pgbouncerプロキシ実装でメモリリークが発生しました。これは修正されました。 |
