Upgrading¶

EDB Postgres Distributedは複数のソフトウェアコンポーネントで構成されているため、アップグレード戦略は、アップグレードされるコンポーネントによって部分的に異なります。

一般に、ローリングアップグレードと呼ばれるアプローチを使用すると、ダウンタイムをほぼゼロでクラスターをアップグレードできます。このアプローチを使用すると、ノードが1つずつアップグレードされ、アプリケーション接続が既にアップグレードされているノードに切り替えられます。

すべてのノードを停止し、すべてのノードでアップグレードを実行してから、クラスター全体を再起動することもできます。このアプローチは、標準のPostgreSQLセットアップと同じです。すべてのノードを同時にアップグレードするこの戦略は、ソフトウェアの混合バージョンでの実行を回避するため、最も簡単です。ただし、ダウンタイムが発生するため、何らかの理由でローリングアップグレードを実行できない場合を除き、お勧めしません。

EDB Postgres分散クラスターをアップグレードするには：

1.アップグレードを計画します。

アップグレードの準備をします。

3.サーバーソフトウェアをアップグレードします。

アップグレードを確認および検証します。

アップグレード計画¶

各ノードをアップグレードするには、大きく2つの方法があります。

*ノードを新しいソフトウェアバージョンにアップグレードします。: ローリングサーバーソフトウェアのアップグレードを参照してください。
*ノードを新しいバージョンがインストールされているものに置き換えます。: ノード参加を使用したローリングアップグレードを参照してください。

これらのアプローチの両方をローリング方式で使用できます。

ローリングアップグレードの考慮事項¶

クラスターのローリングアップグレード中に、ソフトウェアの混合バージョンがクラスターで実行されています。たとえば、nodeAにPGD 3.7.16があり、nodeBとnodeCに4.1.0があるとします。この状態では、レプリケーションとグループ管理は最も古いバージョン（この例では3.7.16）のプロトコルと機能を使用するため、プロトコルの変更を必要とする新しいバージョンが提供する新機能は無効になります。すべてのノードが同じバージョンにアップグレードされると、新機能が有効になります。

同様に、WALデコーダー対応ノードを含むクラスターがローリングアップグレードを行っている場合、より高いバージョンのPGDノードのWALデコーダーは、より高いpglogicalバージョンのLCRを生成します。 PGDノードのより低いバージョンのWALデコーダーは、より低いpglogicalバージョンのLCRを生成します。その結果、上位バージョンのPGDノード上のWAL送信者は、プロトコルバージョンの不一致のため、LCRを使用すると予想されません。 PGDノードのより低いバージョンでは、WAL送信者はLCRを使い続ける場合があります。すべてのPGDノードが同じPGDバージョンになると、WAL送信者はLCRを使用します。

ローリングアップグレードは、すべてのノードが以前のリリースであるクラスターから始まります。次に、すべてのノードが新しいリリースになるまで、一度に1つのノードを新しいリリースにアップグレードします。コンポーネントの3つ以上のバージョンを同時に実行してはなりません。この要件は、以前のアップグレードプロセスがすべてのノードで完全に完了するまで、新しいアップグレードを開始しないことを意味します。

ビジネスリスクを軽減するために注意が必要な場合、アップグレードプロセスにはさらに時間がかかる場合があります。ただし、ソフトウェアの混合バージョンを無期限に実行することはお勧めしません。

ソフトウェアのメジャーバージョンのアップグレードにローリングアップグレードを使用できますが、1つのクラスターでのPostgreSQL、 EDB Postgres Extended、およびEDB Postgres Advanced Serverの混合はサポートされていません。したがって、このアプローチを使用してPostgresバリアントを変更することはできません。

警告

EDB Postgres Distributedのダウングレードはサポートされていません。クラスターを手動でリビルドする必要があります。

ローリングサーバーソフトウェアのアップグレード¶

ローリングアップグレードとは、クラスターの残りの部分の動作を維持しながら、クラスター内の各ノードでローリングサーバーソフトウェアのアップグレードプロセスが順に実行されるプロセスです。

実際の手順は、 Postgresコンポーネントが新しいメジャーバージョンにアップグレードされているかどうかによって異なります。

アップグレードプロセス中に、現在アップグレードされていないノードにアプリケーションを切り替えて、アプリケーションのデータベースの継続的な可用性を提供できます。

ノード参加を使用したローリングアップグレード¶

サーバーソフトウェアをアップグレードする別の方法は、新しいノードをクラスターに参加させ、後で古いバージョンのソフトウェアを実行している既存のノードの1つを削除することです。

このアプローチの場合、手順は常に同じです。ただし、ノードジョインが含まれるため、潜在的に大規模なデータ転送が必要になります。

すべてのノードがPostgresのより新しい同じリリースにアップグレードされるまで、新しいPostgresバージョンでのみ利用可能な機能を使用しないように注意してください。これは、Postgresの新しいリリースに追加された新しいDDL構文に特に当てはまります。

注釈

bdr_init_physical はソースノードのバイトごとのコピーを作成するため、Postgresのメジャーバージョンから別のメジャーバージョンへのアップグレード中に使用することはできません。実際、現在`bdr_init_physical` では、ソースのPGDバージョンと参加ノードがまったく同じである必要があります。新しいノードに参加する方法によるローリングアップグレードには使用できません。代わりに、論理結合を使用してください。

CAMO対応クラスターのアップグレード¶

CAMO対応クラスターをアップグレードするには、 CAMOグループを1つずつアップグレードしながら、アップグレードするグループのCAMO保護を無効にし、新しい

commitスコープへの移行ベースの設定を使用して再構成する必要があります。

CAMOペアを構成する2つのBDRノードをPGD 5.0にアップグレードするには、次のアプローチをお勧めします。

2つのノードのいずれかでのトランザクションでbdr.enable_camo がoff のままであることを確認するか、クライアントを2つのノードからリダイレクトします。 CAMOを使用しようとしているときにCAMOペアリングを削除すると、エラーが発生し、それ以上のトランザクションができなくなります。
bdr.camo_origin_for およびbdr.camo_parter_of （ BDR 3.7.xからアップグレードする場合）をリセットするか、（ BDR 4.xで）bdr.remove_camo_pair を使用して、 CAMOを構成解除して、ペアを分離します。
2つのノードをPGD 5.0にアップグレードします。

・ 2つのノード専用のノードグループを作成し、そのノードグループに移動します。

このノードグループに commitスコープへの移行を作成し、 CAMOを使用するノードのペアを作成します。
default_commit_scope を設定するか、セッションまたはトランザクションにbdr.enable_camo ではなくbdr.commit_scope を明示的に設定するようにクライアントを変更して、 CAMO保護を再度アクティブにします。
必要に応じて、クライアントがCAMO保護ノードに再度接続できるようにします。

アップグレードの準備¶

ソフトウェアの各メジャーリリースには、以前のリリースとの互換性性に影響を与える可能性のあるいくつかの変更が含まれています。これらは、Postgres構成、展開スクリプト、およびPGDを使用するアプリケーションに影響を与える可能性があります。アップグレードの前に、これらの変更を検討し、必要な調整を行うことをお勧めします。

EDB Postgres Distributed Release notes およびバージョン固有のアップグレードノートに記載されている個々の変更を参照してください。

サーバーソフトウェアのアップグレード¶

個々のノードに分散されたEDB Postgresのアップグレードは、その場で行われます。 BDR拡張機能をアップグレードするときに、バックアップと復元する必要はありません。

BDR拡張機能のアップグレード¶

BDR拡張機能のアップグレードプロセスは、いくつかの手順で構成されています。

Postgresを停止します¶

バイナリパッケージのアップグレード中は、通常、実行中のPostgresサーバーを最初に停止するのが最善です。そうすることで、アップグレード中に予期せず再起動した場合に混合バージョンがロードされなくなります。

パッケージのアップグレード¶

アップグレードの最初の手順は、新しいバージョンのBDRパッケージをインストールすることです。このインストールにより、新しいバイナリと拡張機能SQLスクリプトの両方がインストールされます。この手順は、オペレーティングシステムに固有です。

Postgresを起動します¶

パッケージをアップグレードしたら、 Postgresインスタンスを起動できます。 BDR拡張機能は、新しいバイナリが拡張機能の古いバージョンを検出すると、起動時にアップグレードされます。

Postgresのアップグレード¶

Postgresのインプレースアップグレードのプロセスは、Postgresの新しいマイナーバージョンにアップグレードするか、Postgresの新しいメジャーバージョンにアップグレードするかによって異なります。

マイナーバージョンPostgresアップグレード¶

Postgresの新しいマイナーバージョンへのアップグレードは、 upgrading the BDR extensionに似ています。通常、必要なのはPostgresを停止し、パッケージをアップグレードして、Postgresを再起動することだけです。

ただし、特定のマイナーバージョンのアップグレードには、インデックスの再作成などのより多くの手順が推奨される場合があります。アップグレードするPostgresのバージョンのリリースノートを参照してください。

メジャーバージョンPostgresアップグレード¶

Postgresの新しいメジャーバージョンへのアップグレードは、マイナーバージョンへのアップグレードよりも複雑です。

EDB Postgres Distributedは、 In-place Postgres major version upgrades を実行するために使用できる bdr_pg_upgradeコマンドラインユーティリティを提供します。

注釈

Postgres、 BDR拡張機能などを含むソフトウェアの新しいメジャーバージョンにアップグレードするときは、アップグレードするソフトウェアのターゲットバージョンとアプリケーションの互換性を確保することが常に重要です。

アップグレードのチェックと検証¶

PGDノードをアップグレードした後、バイナリの現在のバージョンを確認できます。

SELECT bdr.bdr_version();

ノードをアップグレードした後は常に Monitoring をチェックして、アップグレードされたノードが期待どおりに動作していることを確認します。

HARPからPGDプロキシへの移行¶

HARPは、しばらくの間、新しい接続管理構成と共存できます。これは、次のことができることを意味します。

5より前のクラスター全体をPGD 5クラスターにアップグレードします。
接続ルーティングを設定します。
HARPプロキシをPGDプロキシに置き換えます。
アプリケーション接続をPGDプロキシインスタンスに移動します。
すべてのサーバーからHARP Managerを削除します。

ノードをPGD 5にアップグレードした後、できるだけ早くこれを行うことを強くお勧めします。 HARPは、PGD 5での長期使用が保証されていません。

TPAは、これに役立つツールをいくつか提供し、最終的にはPGD 4とPGD 5間の単一コマンドのアップグレードパスを提供します。