Application schema upgrades#
EDB Postgres Distributedのアップグレードと同様に、アプリケーションスキーマをアップグレードするには2つのアプローチがあります。より簡単なオプションは、影響を受けるすべてのアプリケーションを停止し、スキーマのアップグレードを実行し、新しいスキーマバリアントを使用するようにアップグレードされたアプリケーションを再起動することです。このアプローチでは、ある程度のダウンタイムが発生します。
このダウンタイムを排除するために、 EDB Postgres Distributedは、ローリングアプリケーションスキーマのアップグレードを実行するための便利なツールを提供します。
次の推奨事項とヒントは、クラスターに対するアプリケーションスキーマのアップグレードの影響を軽減します。
ローリングアプリケーションスキーマのアップグレード#
デフォルトでは、 DDLはすべてのノードに自動的に送信されます。 DDL replication で説明しているように、この動作は手動で制御できます。このアプローチを使用して、ノード全体にデータベーススキーマ間の差異を作成できます。
PGDは、ノード間のわずかな違いがあってもレプリケーションを続行できるように設計されています。これらの機能は、ダウンタイムなしでアプリケーションスキーマを移行できるように、またはロジカルスタンバイノードでレポートまたはテストをできるように設計されています。
これを実稼働クラスターで正しく動作させるには、注意的なスクリプトが必要です。広範なテストをお勧めします。
詳細は、 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段階のプロセスが必要です。
NOT NULL制約を削除するか、すべてのノードの列のDEFAULT値を追加します。
カラムを取り外します。
コンストレインは、ローリング方法で削除できます。現在、一度に1ノードずつ、ローリング方法でテーブルコンストレインの追加を処理する方法はありません。
1つのノードが既存の列の型を変更するDDLを実行すると、現在の型とターゲット型間のバイナリ強制性の存在によっては、オペレーションで基になるテーブルデータが書き換えられない場合があります。その場合、それは基になる列タイプのメタデータの更新だけです。テーブルの書き換えは通常制限されています。ただし、制御されたDBA環境では、すべてのノードの非レプリケート環境でこの列のタイプのローリングアップグレードを採用することにより、列のタイプを自動的にキャスト可能なものに変更できます。詳細は、 ALTER TABLE を参照してください。