Upgrading

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

一般に、ノードを1つずつアップグレードし、アプリケーション接続を既にアップグレードされているノードに切り替えるローリングアップグレードと呼ばれるアプローチを使用することにより、アップグレードをほとんどゼロで行うことができます。

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

EDB Postgres分散クラスターをアップグレードするには、次の手順を実行します。

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

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

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

  1. アップグレードを確認して検証します。

アップグレード計画

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

*新しいソフトウェアバージョンへのノードのインプレースアップグレードについては、

ローリングサーバーソフトウェアのアップグレード を参照してください。

*ノードを新しいバージョンがインストールされているものに置き換える。

ノード結合を使用したローリングアップグレード を参照してください。

これらのアプローチは両方ともローリング方式で実行できます。

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

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

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

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

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

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

警告

EDB Postgres Distributedのダウングレードは*サポートされていない*ため、クラスターの手動リビルドが必要です。

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

ローリングアップグレードとは、クラスターの残りの部分の動作を維持しながら、クラスター内の各ノードで Server Software Upgrade プロセスが実行されるプロセスです。

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

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

ノード結合を使用したローリングアップグレード

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

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

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

注釈

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

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

CAMO保護では、CAMOペアのノードの少なくとも1つが動作している必要があります。アップグレードの場合、CAMOで保護されたトランザクションがアップグレードと同時に実行されないようにするか、ローリングアップグレード戦略を使用して、ノードにアップグレードとアップグレードによる対応するノードのダウンタイムを調整するための十分な時間を与えることをお勧めします。

アップグレードの準備

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

Release notes に記載されている個々の変更と、このトピックのバージョン固有のアップグレードノートを参照してください。

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

個々のノードでのEDB Postgres Distributedのアップグレードはインプレースで行われます。 BDR拡張機能をアップグレードする際のバックアップと復元は必要ありません。

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

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

Postgresを停止する

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

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

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

Postgresを起動

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

Postgresのアップグレード

Postgresのインプレースアップグレードのプロセスは、Postgresの新しいマイナーバージョンにアップグレードするかどうかに大きく依存します。

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

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

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

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

Postgresの新しいメジャーバージョンへのアップグレードはより複雑なプロセスです。

EDB Postgres Distributedは、 bdr_pg_upgrade コマンドラインユーティリティを提供します。これを使用して In-place Postgres Major Version Upgrades を実行できます。

注釈

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

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

この手順の後、 BDRノードがアップグレードされます。次のようにBDR4バイナリの現在のバージョンを確認できます。

SELECT bdr.bdr_version();

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

アプリケーションスキーマのアップグレード

BDR自分自身のアップグレードと同様に、アプリケーションスキーマをアップグレードするには2つのアプローチがあります。より簡単なオプションは、影響を受けるすべてのアプリケーションを停止し、スキーマのアップグレードを実行し、アップグレードされたアプリケーションを再起動して新しいスキーマバリアントを使用することです。繰り返しますが、これによりダウンタイムが発生します。

このダウンタイムを解消するために、 BDRはアプリケーションスキーマのローリングアップグレードを実行する方法を提供します。

アプリケーションスキーマのローリングアップグレード

デフォルトでは、 DDLはすべてのノードに自動的に送信されます。これは、

DDL Replication

で説明されているように、手動で制御できます。これを使用して、ノード全体のデータベーススキーマ間の違いを作成できます。 BDRは、ノード間にわずかな違いがある場合でもレプリケーションを続行できるように設計されています。これらの機能は、ダウンタイムなしでアプリケーションスキーマを移行できるように、またはロジカルスタンバイノードでレポートまたはテストを行えるように設計されています。

警告

ローリングアプリケーションスキーマのアップグレードはBDRの外部で管理する必要があります。実稼働クラスターでこれを正しく機能させるには、慎重なスクリプトが必要です。大規模なテストをお勧めします。

詳細は Replicating between nodes with differences を参照してください。

1つのノードが新しいテーブルを追加するDDLを実行すると、最新のDDLをまだ受け取っていないノードは余分なテーブルを処理する必要があります。この観点から、ローリングスキーマアップグレードの適切な設定は、 target_table_missing の競合が発生した場合にskip リゾルバーを適用するようにすべてのノードを構成することです。これは、ノードに追加のテーブルを追加する前に実行する必要があります。永続的な設定を目的としています。

これは、 node1 を実際のノード名に置き換えた後、次のクエリで実行されます。

SELECT bdr.alter_node_set_conflict_resolver(node1,
        target_table_missing, skip);

1つのノードがテーブルに列を追加するDDLを実行すると、最新のDDLをまだ受け取っていないノードは追加の列を処理する必要があります。この観点から、ローリングスキーマアップグレードの適切な設定は、 target_column_missing の競合が発生した場合にignore リゾルバーを適用するようにすべてのノードを構成することです。これは、1つのノードに列を追加する前に実行する必要があります。永続的な設定を目的としています。

これは、 node1 を実際のノード名に置き換えた後、次のクエリで実行されます。

SELECT bdr.alter_node_set_conflict_resolver(node1,
        target_column_missing, ignore);

1つのノードがテーブルから列を削除するDDLを実行する場合、最新のDDLをまだ受け取っていないノードは不足している列を処理する必要があります。この状況により、 use_default_value リゾルバーを使用するsource_column_missing の競合が発生します。したがって、 NULL を受け入れず、 DEFAULT 値を持たない列には、2つのステップのプロセスが必要です。

  1. NOT NULL制約を削除するか、すべてのノードの列にDEFAULT値を追加します。

  2. カラムを取り外します。

制約はローリングで削除できます。現在、テーブル制約の追加を一度に 1 ノードずつ処理する方法はサポートされていません。

1つのノードが既存の列の型を変更するDDLを実行する場合、現在の型とターゲットの型間のバイナリ強制性の存在によっては、操作で基になるテーブルデータが書き換えられない場合があります。その場合、基になる列タイプのメタデータの更新のみになります。通常、テーブルの書き換えは制限されています。ただし、制御されたDBA環境では、すべてのノードの非レプリケート環境でこの列の型のローリングアップグレードを1つずつ採用することにより、列の型を自動的にキャスト可能なものに変更できます。詳細については、 ALTER TABLE を参照してください。セクション。