Application Schema Upgrades¶

この章では、 BDRクラスター上のソフトウェアのアップグレード処理と、アップグレード中のアプリケーションのダウンタイムを最小限に抑える方法について説明します。

概要¶

BDRクラスターには、基礎となるPostgreSQLソフトウェアまたはそのフレーバーとPGLogical / BDRソフトウェアの2つのソフトウェアセットがあります。これらのソフトウェアバージョンのいずれかまたは両方を、サポートされているメジャーリリースにアップグレードすることについて説明します。

BDRクラスターをアップグレードするには、各ノードで次の手順を実行する必要があります。

アップグレードを計画する
アップグレードの準備
サーバソフトウェアのアップグレード Postgresをリスタートします
アップグレードの確認と検証

アップグレード計画¶

BDR 3.7リリースはPostgreSQL 11-13をサポートしていますが、 BDR 4.0はPostgreSQLバージョン12-14をサポートしています。完全なリスト互換ソフトウェアについては、（product-matrix.md）ページを参照してください。 BDR 4.0は新しいPostgreSQLリリースをサポートしているため、 BDR 3.7からBDR 4.0へのアップグレード処理中に、アプリケーションのダウンタイムを最小限に抑えるか、まったく停止せずに新しいPostgreSQLリリースをアップグレードすることもできます。

BDRバージョンをアップグレードするには、大きく2つの方法があります。

一度に1つのノードを新しいBDRバージョンにアップグレードします。
新しいバージョンのBDRソフトウェアを実行している新しいノードに参加し、その後、オプションで古いノードの1つをドロップします。

BDRソフトウェアのアップグレード処理のみに関心がある場合は、2つの方法のいずれかを使用できます。ただし、PostgreSQLバージョンもアップグレードする場合は、2番目のメソッドを使用する必要があります。

!!! Warning * 現在、最初のメソッドを使用してBDR 3.7からBDR 4.0にアップグレードすることはできません。 3.7を4.0にアップグレードする唯一の方法は、Rolling Upgrade Using Node Joinセクションで説明されているように、4.0ノードをBDR 3.7クラスターに結合させることです。この制約は、 BDR 4の将来のバージョンで解除される可能性があります。

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

ローリングアップグレードとは、レプリケーションを機能させたまま、BDRグループの各ノードで次のServerSoftware Upgradeを次々に実行するプロセスです。

4.0へのアップグレードは、3.7からのみサポートされ、特定の最小メンテナンスリリース（3.7.13.1など）を使用します。実際に必要な最小バージョンについては、リリースノートを参照してください。そのため、ノードが古い3.7リリースで実行されている場合、最初に最低限必要なバージョンにアップグレードする必要があり、その後でのみ4.0にアップグレードできます。

単一ノードのデータベースと同様に、すべてのノードを停止し、すべてのノードでアップグレードを実行してから、クラスター全体をリスタートすることができます。すべてのノードを同時にアップグレード処理この戦略は、混在BDRバージョンでの実行を回避するため、最も簡単ですが、明らかにダウンタイムが発生します。

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

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

BDRクラスターは、簡単にアップグレードできるように設計されています。ほとんどのBDRリリースはローリングアップグレードをサポートしています。つまり、1つのリリースレベルでクラスターのパートを実行し、2番目の互換性のあるリリースレベルでクラスターの残りのパートを実行します。

ローリングアップグレードは、以前のリリースのすべてのノードを含むクラスターで開始され、その後、すべてのノードが新しいリリースになるまで、一度に1つのノードを新しいリリースにアップグレード処理します。問題が発生した場合は、技術サポートに連絡してオプションについて話し合って提供することなく、ダウングレードを試みないでください。

ユーザがビジネスリスクを軽減するために注意が必要であると判断した場合、アップグレードプロセスには拡張かかる場合がありますが、2つのリリースレベルの共存期間を延長するためのTechnicalSupportからの議論と明示的な同意なしに30日以上かかることはありません。

アップグレード中に問題が発生した場合、新しい/異なるリリースレベルへの2回目のアップグレードを開始しないでください。通常の使用では、2つのアップグレードが同時に発生することはありません。テクニカルサポートからの具体的かつ明示的な指示がない限り、ノードを3番目のリリースにアップグレードしないでください。これが発生する可能性があるのは、何らかの理由でアップグレードが失敗し、現在のクラスターアップグレードプロセスを継続して成功するためにホットフィックスが必要な場合です。 BDRは2つ以上のリリースレベルで設計およびテストされていますが、特定の場合を除き、稼動環境での使用に依存することはできません。

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

基礎となるPostgreSQLメジャーバージョンのアップグレードの有無にかかわらず、 BDRソフトウェアをアップグレード処理もう1つのメソッドは、新しいノードをクラスターに結合させ、古いバージョンのソフトウェアを実行している既存のノードの1つを後でドロップすることです。このメソッドでも、すべてのノードが最終的に新しいバージョンにアップグレードされるまで、ソフトウェアの新しいバージョンでのみ使用可能な一部の機能は使用できない場合があります。

このリリースのBDR 4.0を実行している新しいノードは3.7クラスターに結合でき、クラスター内の各ノードは最新の3.7.xバージョンのBDRを実行しています。参加ノードは、サポートされているPostgreSQLバージョン12〜14のいずれかを実行できますが、 PostgreSQL、 EDB Postgres Extended、およびEDB Postgres Advancedの混合は現在サポートされていません。

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

bdr_init_physicalはソースノードをバイト単位で作成することに注意してください。そのため、1つのメジャーPostgreSQLバージョンから別のバージョンにアップグレード処理際には使用できません。実際、現在bdr_init_physicalでは、ソースと結合ノードのEvenBDRバージョンが完全に同じである必要があります。 Soitは、新しいノードメソッドに参加することによるローリングアップグレードには使用できません。そのような場合はすべて、ロジカル結合を使用する必要があります。

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

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

CAMOペアの構成がBDR3.7と比較して大幅に変更されました。postgresql.confのGUCの代わりに、ペアリングはBDRシステムカタログbdr.camo_pairsに保存されるようになりました。 CAMOペアを含むBDRクラスターを3.7から4.0にアップグレードするには、次の手順を実行する必要があります。

bdr.camo_partner_ofとbdr.camo_origin_forを削除しますすべてのノードの構成。
この変更の影響を受けるすべてのノードを再起動します（既存の BDRバージョン）、1つずつ。これにより、CAMOが一時的に無効になります bdr.enable_camoを設定してトランザクションを実行しようとすると警告になります。
すべてのノードをBDRに、またはローリングアップグレード。
bdr.add_camo_pairを使用してCAMOを再構成します。このファンクションは BDRクラスター内のすべてのノードがアップグレードされた後にのみ機能します。

アップグレードの準備¶

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

pglogical¶

pglogical4は存在せず、shared_preload_librariesを介してpglogicalのいずれかのバージョンがPostgresの同じインスタンスにロードされた場合、BDR4は機能しません。

ノード管理¶

bdr.create_node_group()ファンクションには多くの変更があります。

サブグループを作成できるようになり、グループツリーが作成されます。 BDRクラスター全体の構造。監視ビューが更新されましたそれに応じて。
非推奨のパラメーターinsert_to_update、update_to_insert、 ignore_redundant_updates、check_full_tuple、およびapply_delayは削除されました。 insert_to_updateの代わりにbdr.alter_node_set_conflict_resolver()を使用します。 update_to_insert。 check_full_tupleはそのままでは不要ですテーブル競合検出構成に基づいて自動的に処理されます。

競合¶

競合の解決とロギングの設定は、新しいノードでデフォルトを使用するのではなく、結合ソースノードから新しく結合するノードにコピーされるようになりました。

一部の競合タイプのデフォルトの競合解決が変更されました。新しいデフォルトについては、（conflicts.md＃default-conflict-resolvers）を参照してください。

競合ロギングインターフェイスは、bdr.alter_node_add_log_configおよびbdr.alter_node_remove_log_configからbdr.alter_node_set_log_configに変更されました。

デフォルトの競合ロギングテーブルの名前付けはbdr.conflict_historyになり、古いbdr.apply_logは存在しなくなりました。新しいテーブルは、 BDRのAutopartition機能を使用してパーティション化されます。

すべての競合がデフォルトでログファイルと競合テーブルの両方に記録されるようになりました。

廃止された関数bdr.row_version_tracking_enable()とbdr.row_version_tracking_disable()は削除されました。代わりに、edbdr.alter_table_conflict_detection()を使用します。

競合ハンドリングの構成の一部は、edpglogicalスキーマに格納されなくなりました。 pglogicaltablesを直接使用していた診断クエリは、bdrスキーマの適切なテーブルにスイッチ必要があります。

削除または名前変更された設定（GUC）¶

代わりにbdr.prefixを使用するように、接頭辞付きのpglogical.構成変数はすべて名前が変更されました。

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

個々のノードでのBDRソフトウェアのアップグレードはインプレースで行われます。 BDR拡張機能をアップグレード処理する場合、バックアップと復元には必要ありません。

!!! Warning * 現在、このメソッドはBDR 3.7から4.0へのアップグレード処理には使用できません。 3.7を4.0にアップグレードする唯一の方法は、Rolling Upgrade Using Node Joinセクションで説明されているように、4.0ノードをBDR 3.7クラスターに結合させることです。この制約は、 BDR 4の将来のバージョンで解除される可能性があります。

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

Postgresを再起動する¶

バイナリおよび拡張スクリプトを自分自身でアップグレードしても、実行中のPostgreSQLインスタンスのBDRはアップグレードされません。そのためには、 PostgreSQLインスタンスを再起動して、新しいBDRバイナリをロードできるようにする必要があります（ BDRバイナリはPostgreSQLサーバーのスタートにロードされます）。その後、ノードがアップグレードされます。拡張SQLアップグレードスクリプトは、必要に応じて自動的に実行されます。

!!! Warning * PostgreSQLインスタンスを再起動する前にALTER EXTENSION ... UPDATEコマンドを実行しないことが重要です。これは、 SQLに見える拡張機能をアップグレードするだけで、古いバイナリを保持するため、予期しない動作やクラッシュを引き起こす可能性があります。 ALTER EXTENSION ... UPDATEコマンドは必要ありません。 BDR4は、必要に応じてSQLに見える拡張機能を自動的に維持します。

アップグレードの確認と検証¶

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

SELECT bdr.bdr_version();

ノードのアップグレード後に必ずmonitoringをチェックして、アップグレードされたノードが期待どおりに機能していることを確認しノード。

データベースのエンコード¶

すべての複製データベースでUTF-8エンコーディングを使用することをお勧めします。 BDRは、異なるエンコーディングのデータベース間のレプリケーションをサポートしていません。現在、/ alter エンコーディングをアップグレードするためのサポートされているパスはありません。

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

このダウンタイムをなくすために、 BDRは、次のセクションで説明されているように、ローリングアプリケーションスキーマのアップグレードを実行する方法を提供します。

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

デフォルトでは、 DDLはすべてのノードに自動的に送信されます。これは、DDL Replicationで説明されているように、手動で制御できます。これは、ノード間でデータベーススキーマの違いを作成するために使用できます。 BDRは、ノード間にわずかな違いがある場合でもレプリケーションを続行できるように設計されています。これらの機能は、ダウンタイムなしでアプリケーションスキーマを移行したり、レポートまたはテスト用に論理スタンバイノードを許可したりするように設計されています。

!!! Warning * アプリケーションスキーマのアップグレードは、 BDRではなくユーザが管理します。これを稼動クラスターで正しく機能さmakeには、慎重なスクリプト作成が必要になります。広範なテストが推奨されます。

詳細については、hereReplicating between nodes with differencesをご覧ください。

1つのノードが新しいテーブルを追加するDDLを実行する場合、まだ最新のDDLを受け取っていないノードは、リゾルバビューテーブルに対処する必要がありスキーマ。 atarget_table_missingの競合の場合。これは、任意のノードに追加のテーブルを追加する前に実行する必要があり、永続的な設定を目的としています。

これは、node1を実際のノード名前に置き換えた後、各ノードで別々に実行する必要がある次のクエリーで行われます：

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

1つのノードがテーブルに列を追加するDDLを実行する場合、まだ最新のDDLを受け取っていないノードは追加の列に対処する必要がありビュー。 target_column_missing競合のリゾルバ。これは、1つのノードに追加の列が追加される前に実行する必要があり、永続的な設定を目的としています。