Upgrading PGD clusters manually#

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

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

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

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

  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つまでです。別のアップグレードを開始する前に、すべてのノードを完全にアップグレードした状態でアップグレードを完了する必要があります。

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

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

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を使用するノードのペアを作成します。

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

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

アップグレードの準備#

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

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

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

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

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

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

Postgresを停止します#

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

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

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

Postgresを開始する#

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

Postgresのアップグレード#

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

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

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

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

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

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

EDB Postgres Distributedは、 In-place Postgres or Postgres and PGD major version upgrades を実行するために使用できるpgdノードアップグレードコマンドラインユーティリティを提供します。

注釈

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

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

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

SELECT bdr.bdr_version();

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

HARPからPGDプロキシへの移動#

HARPは、新しい Routing functions 構成と一時的に共存できます。これは、次のことができることを意味します。

  • pre-5クラスター全体をPGD 5クラスターにアップグレードします。

  • 接続ルーティングを設定します。

  • HARPプロキシをPGDプロキシに置き換えます。

  • アプリケーション接続をPGDプロキシインスタンスに移動します。

  • すべてのサーバーからHARP Managerを削除します。

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

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