他のバージョンの文書 16 | 15 | 14 | 13 | 12 | 11 | 10 | 9.6 | 9.5 | 9.4 | 9.3 | 9.2 | 9.1 | 9.0 | 8.4 | 8.3 | 8.2 | 8.1 | 8.0 | 7.4 | 7.3 | 7.2

31.1. パブリケーション #

パブリケーションは、どのような物理レプリケーションのプライマリにも定義できます。 パブリケーションが定義されたノードは、パブリッシャーと呼ばれます。 パブリケーションは、テーブルか、テーブルのグループから生成された更新の集合であると同時に、更新セットあるいはレプリケーションセットであるとも言えます。 一つのパブリケーションは一つのデータベースにのみ存在します。

パブリケーションはスキーマとは異なり、テーブルがどのようにアクセスされるかには影響しません。 必要ならば、テーブルを複数のパブリケーションに追加できます。 今のところパブリケーションはテーブルとスキーマのすべてのテーブルのみを含むことができます。 パブリケーションがALL TABLESで作られた場合を除き、オブジェクトは明示的に追加されなければなりません。

パブリケーションは、生成される更新を、INSERTUPDATEDELETETRUNCATEのうちのどのような組み合わせにも制限することができます。 これはトリガーが特定のイベント型によって起動されることに似ています。 デフォルトでは、すべての操作タイプがレプリケーションされます。 これらのパブリケーション指定はDML操作にのみ適用され、初期データ同期コピーには影響しません(行フィルタはTRUNCATEには影響しません。31.3を参照してください)

パブリッシュされたテーブルは、UPDATEDELETEをレプリケーションできるようにするために、レプリカアイデンティティの設定を含んでいなければなりません。 そうすることにより、サブスクライバー側で更新または削除する対象の正しい行が特定できるようになります。 デフォルトでは主キーがあれば、それがレプリカアイデンティティになります。 他に、ユニークキー(追加の要件を伴います)もレプリカアイデンティティにできます。 テーブルに適当なキーがなければ、レプリカアイデンティティをFULLにできます。 これは、行全体がキーになることを意味します。 レプリカアイデンティティFULLを指定すると、行の検索にサブスクライバー側でインデックスが使えます。 候補となるインデックスはBツリーでなければならず、部分的であってはなりません。そして、左端のインデックスのフィールドはパブリッシュされたテーブル列を参照する(式でない)列でなければなりません。 一意でないインデックスの属性に関するこれらの制限は、主キーに強制される制限の一部に準拠しています。 そのような適切なインデックスがない場合には、サブスクライバー側での検索は非常に非効率なる可能性があるので、レプリカアイデンティティFULLは他の解決方法がない場合のみの代替手段にすべきです。 FULL以外のレプリカアイデンティティがパブリッシャー側に設定されている場合、同じか、より少ない列を含むレプリカアイデンティティがサブスクライバー側に設定されていなければなりません。 レプリカアイデンティティを設定する詳細な方法については、REPLICA IDENTITYをご覧ください。 UPDATEあるいはDELETE操作をレプリケーションするパブリケーションに、レプリカアイデンティティがないテーブルが追加されると、以後UPDATEあるいはDELETE操作が行われるとパブリッシャー側でエラーが発生します。 INSERT操作は、レプリカアイデンティティの設定に関わらず実行されます。

すべてのパブリケーションは、複数のサブスクライバーを持つことができます。

パブリケーションは、CREATE PUBLICATIONコマンドで作成し、対応するコマンドで変更や削除ができます。

個々のテーブルはALTER PUBLICATIONで動的に追加削除できます。 ADD TABLEおよびDROP TABLE操作はトランザクションの対象です。 ひとたびトランザクションがコミットされれば、正しいスナップショットでテーブルのレプリケーションが開始あるいは終了されます。