Upgrading PGD clusters manually

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

通常、 ローリングアップグレード と呼ばれるアプローチを使用して、ほぼゼロのダウンタイムでクラスターをアップグレードできます。このアプローチを使用して、ノードは1つずつアップグレードされ、アプリケーション接続は既にアップグレードされたノードにスイッチオーバーされます。

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

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

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

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

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

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

アップグレード計画

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

• ノードを新しいソフトウェアバージョンにアップグレードします。 ローリングサーバーソフトウェアのアップグレード を参照してください。

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

これらのアプローチは両方ともローリング方法で使用できます。

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

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

同様に、WALデコーダー対応ノードを含むクラスターがローリングアップグレードを実行している場合、高いバージョンのPGDノードのWALデコーダーは、より高いpg論理バージョンで logical change records (LCRs) を生成します。 PGDノードの下位バージョンのWALデコーダは、下位のpg論理バージョンのLCRを生成します。その結果、プロトコルバージョンの不一致のため、PGDノードの上位バージョンのWAL送信者はLCRを使用することは想定されていません。 PGDノードの下のバージョンでは、WAL送信者は引き続きLCRを使用できます。すべてのPGDノードが同じPGDバージョンになると、WAL送信者はLCRを使用します。

ローリングアップグレードは、以前のリリースのすべてのノードを含むクラスターで開始されます。次に、すべてのノードが新しいリリースになるまで、一度に1つのノードを新しいリリースにアップグレードして続行します。同時に実行されるソフトウェアのバージョンは3つまでです。別のアップグレードを開始する前に、すべてのノードを完全にアップグレードした状態でアップグレードを完了する必要があります。

ビジネスリスクを削減するために追加の注意が必要な場合、アップグレードの実行により多くの時間が必要になる場合があります。最大限の注意を払い、実稼働システムのアップグレードに必要な時間を削減するために、最初に別のテスト環境でアップグレードを実行することをお勧めします。

アップグレードを完了するために絶対に必要な時間を超えて、ソフトウェアの混合バージョンで実行しないでください。 pgd commit-scopes list コマンドを使用して、クラスター内のバージョンを確認できます。

混合バージョンでの実行が長くなると、問題が発生する可能性が高くなり、それらの診断と解決が難しくなります。 ビジネスのオフピーク時間に、短期間にアップグレードすることをお勧めします。

ローリングアップグレードを使用してソフトウェアのメジャーバージョンをアップグレードすることはできますが、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 scope ベースの設定を使用して再構成する必要があります。

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

1. 2つのノードのいずれか上のトランザクションでbdr.enable_camo がoff のままであることを確認するか、クライアントを2つのノードからリダイレクトします。 CAMOを使用しようとするときにCAMOペアリングを削除すると、エラーが発生し、それ以上のトランザクションが防止されます。

2. bdr.camo_origin_for およびbdr.camo_parter_of をリセットすることによりBDR 3.7.xからアップグレードする場合、またはbdr.remove_camo_pair BDR 4.xのいずれかによりCAMOの構成を解除することにより、ペアのカップリングを解除します。

3. 2つのノードをPGD 5.0にアップグレードします。

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

5. このノードグループ、およびCAMOを使用するノードのペアの commit scope を作成します。

6. default_commit_scope を設定するか、セッションまたはトランザクションにbdr.enable_camo の代わりにbdr.commit_scope を明示的に設定するようにクライアントを変更することにより、 CAMO保護を再度アクティブにします。

7. 必要に応じて、クライアントがCAMO保護ノードに再度接続できるようにします。

アップグレードの準備

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

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

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

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

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

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

ノードをフェンスする

アップグレードが完了するまで、アップグレードされるノードが書き込みリーダーにならないように、アップグレードを開始する前にノードをフェンスする必要があります。

Postgresを停止します

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

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

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

Postgresを開始する

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

ノードのフェンスを解除します

ノードのアップグレードが完了した後、ノードのフェンスを解除できます。

　　PGD 6.1にアップグレードする前に、 PGD 4クラスターはPGD 　　4.4を実行している必要があります。

PGD 4.4からPGD 6.1にアップグレードするには、HarpプロキシからConnection Managerに移動する追加の手順が必要です。詳細については、実際の例 実際の例 PGD 4からPGD 6.1へのアップグレード を参照してください。

PGD 6.1にアップグレードする前に、 PGD 5クラスターはPGD 5.9を実行している必要があります。

PGD 5.9からPGD 6.1にアップグレードするには、 PGDプロキシからConnection Managerに移動する追加の手順が必要です。 詳細については、実際の例 実際の例 PGD 5からPGD 6.1へのアップグレード を参照してください。

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

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

Postgresの新しいマイナーバージョンへのアップグレードは、 BDR拡張機能のアップグレード に似ています。通常、Postgresの停止、パッケージのアップグレード、およびPostgresの再起動だけが必要なすべてです。

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

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

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

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

注釈

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

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

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

SELECT bdr.bdr_version();

ノードをアップグレードした後は常に monitoring をチェックして、アップグレードされたノードが予想通りに動作していることを確認します。

PGD 5- PGDプロキシから接続マネージャーへの移動

次の手順を使用して、PGDプロキシから接続マネージャーに移動します。

1. PGD 5.9ノードのいずれかから次のクエリーを実行して、すべてのユーザーパスワードのSCRAMハッシュがすべてのノードで同じであることを確認します。

• DO $$
  DECLARE
      rec RECORD;
      command TEXT;    password TEXT;
  BEGIN
      FOR rec IN SELECT rolname,rolpassword FROM pg_authid WHERE rolcanlogin = true AND rolpassword like SCRAM-SHA%
      LOOP
          password := rec.rolpassword;
          command := ALTER ROLE  || quote_ident(rec.rolname) ||  WITH ENCRYPTED PASSWORD  || quote_literal(password);
          EXECUTE command;
      END LOOP;
  END;
  $$;
  SELECT wait_slot_confirm_lsn(NULL, NULL);
  

これを実行した後、新しいユーザーは5.9に追加されません。追加された場合は、クエリを再度実行します。上記のブロックはパスワードを変更しません。すべてのノードのクラスターでSCRAMハッシュが同じであることを保証するだけです。 .. ::

2. 書き込みリーダーにならないように、pgd node <node-name> set-option route_fence true を使用してこのクラスター内のノードをフェンスします。 3. GUC bdr.enable_builtin_connection_manager を*true*に有効にします。 4.サーバーを再起動します。 5.サーバーで実行されているPGDプロキシを停止します。 6.サーバーを再起動します。デフォルトのポートで実行されている接続マネージャーで起動します。プロキシの読み取りポートと書き込みポートが異なる場合、Connection Managerポートの読み取りポートと書き込みポートは、 bdr.alter_node_group_option() によってプロキシと同じになるように変更できます。 7.ノードのフェンスを解除します。 このノードは、ユーザーからの接続を受け入れ、接続マネージャーを介して書き込みリーダーにルーティングできるようになりました。 8. クラスター内のノードごとにこれを繰り返します。 これにより、すべてのノードが接続マネージャーを介してルーティングされるようになります。 9. PGD 5からPGD 6.1へのメジャーバージョンのアップグレードも実行する場合は、 rolling upgrade steps に進みます。