Movatterモバイル変換


[0]ホーム

URL:



Facebook
Postgres Pro
Facebook
Downloads
29.1. Publication
Prev UpChapter 29. Logical ReplicationHome Next

29.1. Publication#

Apublication can be defined on any physical replication primary. The node where a publication is defined is referred to aspublisher. A publication is a set of changes generated from a table or a group of tables, and might also be described as a change set or replication set. Each publication exists in only one database.

Publications are different from schemas and do not affect how the table is accessed. Each table can be added to multiple publications if needed. Publications may currently only contain tables and all tables in schema. Objects must be added explicitly, except when a publication is created forALL TABLES.

Publications can choose to limit the changes they produce to any combination ofINSERT,UPDATE,DELETE, andTRUNCATE, similar to how triggers are fired by particular event types. By default, all operation types are replicated. These publication specifications apply only for DML operations; they do not affect the initial data synchronization copy. (Row filters have no effect forTRUNCATE. SeeSection 29.4).

A published table must have areplica identity configured in order to be able to replicateUPDATE andDELETE operations, so that appropriate rows to update or delete can be identified on the subscriber side. By default, this is the primary key, if there is one. Another unique index (with certain additional requirements) can also be set to be the replica identity. If the table does not have any suitable key, then it can be set to replica identityFULL, which means the entire row becomes the key. When replica identityFULL is specified, indexes can be used on the subscriber side for searching the rows. Candidate indexes must be btree or hash, non-partial, and the leftmost index field must be a column (not an expression) that references the published table column. These restrictions on the non-unique index properties adhere to some of the restrictions that are enforced for primary keys. If there are no such suitable indexes, the search on the subscriber side can be very inefficient, therefore replica identityFULL should only be used as a fallback if no other solution is possible. If a replica identity other thanFULL is set on the publisher side, a replica identity comprising the same or fewer columns must also be set on the subscriber side. SeeREPLICA IDENTITY for details on how to set the replica identity. If a table without a replica identity is added to a publication that replicatesUPDATE orDELETE operations then subsequentUPDATE orDELETE operations will cause an error on the publisher.INSERT operations can proceed regardless of any replica identity.

Every publication can have multiple subscribers.

A publication is created using theCREATE PUBLICATION command and may later be altered or dropped using corresponding commands.

The individual tables can be added and removed dynamically usingALTER PUBLICATION. Both theADD TABLE andDROP TABLE operations are transactional; so the table will start or stop replicating at the correct snapshot once the transaction has committed.


Prev Up Next
Chapter 29. Logical Replication Home 29.2. Subscription
pdfepub
Go to PostgreSQL 17
By continuing to browse this website, you agree to the use of cookies. Go toPrivacy Policy.

[8]ページ先頭

©2009-2025 Movatter.jp