この記事では、サブスクリプション関連の情報を紹介します。
概要
サブスクリプションは、論理レプリケーションの下流側です。 サブスクリプションが定義されるノードは、サブスクライバと呼ばれる。 サブスクリプションは、サブスクライブしたい別のデータベースおよびパブリケーションのセット (1つまたは複数) への接続を定義します。
サブスクライバーデータベースは、他のPostgreSQLインスタンスと同じように動作し、独自のパブリケーションを定義することで他のデータベースのパブリッシャーとして使用できます。
加入者ノードは、必要に応じて複数のサブスクリプションを有する。 単一のパブリッシャ − サブスクライバ対の間に複数のサブスクリプションを定義することが可能であり、その場合、サブスクライブされたパブリケーションオブジェクトが重複しないことを確実にするように注意しなければならない。
各サブスクリプションは、1つのレプリケーションスロットを介して変更を受け取ります。 既存のテーブルデータの初期データ同期には追加の複製スロットが必要になる場合があり、それらはデータ同期の終了時にドロップされます。
論理レプリケーションサブスクリプションは、同期レプリケーションのスタンバイにすることができます。 スタンバイ名はデフォルトでサブスクリプション名です。 代替名は、サブスクリプションの接続情報でapplication_nameとして指定できます。
現在のユーザーがスーパーユーザーの場合、サブスクリプションはpg_dumpによってダンプされます。 そうしないと、スーパーユーザー以外のユーザーがpg_subscriptionカタログからすべてのサブスクリプション情報を読み取ることができないため、警告が書き込まれ、サブスクリプションはスキップされます。
サブスクリプションはCREATE subscriptionを使用して追加され、ALTER SUBSCRIPTIONコマンドを使用していつでも停止 /再開でき、DROP SUBSCRIPTIONを使用して削除できます。
サブスクリプションがドロップされて再作成されると、同期情報が失われます。 これは、データが後で再同期されなければならないことを意味する。
スキーマ定義はレプリケートされず、パブリッシュされたテーブルはサブスクライバに存在する必要があります。 通常のテーブルのみがレプリケーションのターゲットになります。 たとえば、ビューにレプリケートすることはできません。
テーブルは、完全修飾テーブル名を使用してパブリッシャとサブスクライバの間で照合されます。 サブスクライバ上の異なる名前のテーブルへのレプリケーションはサポートされていません。
テーブルの列も名前で照合されます。 購読者テーブル内の列の順序は、発行者のものと一致する必要はない。 列のデータ型は、データのテキスト表現をターゲット型に変換できる限り、一致する必要はありません。 たとえば、integer型の列からbigint型の列にレプリケートできます。 ターゲットテーブルは、パブリッシュされたテーブルによって提供されない追加の列を持つこともできます。 このような列には、ターゲットテーブルの定義で指定されたデフォルト値が入力されます。
レプリケーションスロット管理
前述のように、各 (アクティブな) サブスクリプションは、リモート (パブリッシング) 側のレプリケーションスロットから変更を受け取ります。
通常、リモートレプリケーションスロットは、CREATE subscriptionを使用してサブスクリプションを作成すると自動的に作成され、DROP SUBSCRIPTIONを使用してサブスクリプションを削除すると自動的に削除されます。 しかし、いくつかの状況では、サブスクリプションと基礎となる複製スロットを別々に操作することが有用または必要となり得る。 いくつかのシナリオは次のとおりです。
サブスクリプションを作成するとき、レプリケーションスロットはすでに存在します。 その場合、
create_slot = falseオプションを使用してサブスクリプションを作成し、既存のスロットに関連付けることができます。サブスクリプションを作成すると、リモートホストに到達できないか、不明な状態になります。 その場合、サブスクリプションは
connect = falseオプションを使用して作成できます。 この場合、リモートホストには全く連絡が取られない。 これはwhatpg_dumpusesです。 次に、サブスクリプションをアクティブ化する前に、リモート複製スロットを手動で作成する必要があります。サブスクリプションをドロップするときは、レプリケーションスロットを保持する必要があります。 これは、加入者データベースが異なるホストに移動され、そこから起動されるときに有用である。 その場合、サブスクリプションのドロップを試みる前に、
ALTER subscriptionを使用してサブスクリプションからスロットの関連付けを解除します。サブスクリプションを削除すると、リモートホストにアクセスできなくなります。 その場合、サブスクリプションのドロップを試みる前に、
ALTER subscriptionを使用してサブスクリプションからスロットの関連付けを解除します。 リモートデータベースインスタンスがもはや存在しない場合、さらなるアクションは必要ではない。 しかし、リモート・データベース・インスタンスがちょうど到達不可能である場合、複製スロット (および任意のまだ残っているテーブル同期スロット) は、手動でドロップされるべきである。 そのようなケースは慎重に調査されるべきです。