Application schema upgrades¶
EDB Postgres Distributedのアップグレードと同様に、アプリケーションスキーマをアップグレードするには2つのアプローチがあります。より簡単なオプションは、影響を受けるすべてのアプリケーションを停止し、スキーマのアップグレードを実行し、アップグレードされたアプリケーションを再起動して新しいスキーマバリアントを使用することです。このアプローチでは、ダウンタイムが発生します。
このダウンタイムを解消するために、 EDB Postgres Distributedは、アプリケーションスキーマのローリングアップグレードを実行するための便利なツールを提供します。
次の推奨事項とヒントは、クラスターに対するアプリケーションスキーマのアップグレードの影響を軽減します。
ローリングアプリケーションスキーマのアップグレード¶
- デフォルトでは、 DDLはすべてのノードに自動的に送信されます。
DMLおよびDDLレプリケーション で説明されているように、この動作を手動で制御できます。このアプローチを使用して、ノード全体のデータベーススキーマ間の違いを作成できます。
PGDは、ノード間のわずかな違いがあってもレプリケーションを継続できるように設計されています。これらの機能は、ダウンタイムなしでアプリケーションスキーマを移行できるように、またはロジカルスタンバイノードでレポートまたはテストを行えるように設計されています。
警告
PGDの外部でアプリケーションスキーマのローリングアップグレードを管理する必要があります。
これを実稼働クラスターで正しく機能させるには、慎重なスクリプト作成が必要です。広範なテストをお勧めします。
詳細は 差分のあるノード間のレプリケーション を参照してください。
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環境では、すべてのノードの非レプリケート環境でこの列の型のローリングアップグレードを1つずつ採用することにより、列の型を自動的にキャスト可能なものに変更できます。詳細については、 ALTERテーブル を参照してください。
