Une publication peut être définie sur n'importe quel serveur primaire de réplication physique. Le nœud sur laquelle la publication est définie est nommé publieur. Une publication est un ensemble de modifications générées par une table ou un groupe de tables et peut aussi être défini comme un ensemble de modifications ou un ensemble de réplication. Chaque publication existe au sein d'une seule base de données.
Les publications sont différenciées du schéma et n'ont pas d'impact sur la
manière dont la base est accédée. Chaque table peut être ajoutée à
différentes publications au besoin. Actuellement, les publications ne
contiennent que les tables et toutes les tables d'un schéma. Les objets
doivent être ajoutés explicitement, sauf si la publication a été créée pour
toutes les tables (ALL TABLES).
Les publications peuvent choisir de limiter les changements qu'elles
produisent avec n'importe quelle combinaison de INSERT,
UPDATE, DELETE et
TRUNCATE, ceci d'une façon similaire à l'activation de
triggers en fonction d'un certain type d'événement. Par défaut, tous les
types d'opération sont répliqués. Ces spécifications de publication
s'appliquent seulement pour les opérations DML ; elles n'affectent pas
la copie initiale de synchronisation des données. (Les filtres de ligne
n'ont pas d'effet pour la commande TRUNCATE. Voir Section 29.4.)
Chaque publication peut avoir plusieurs abonnés.
Une publication est créée en utilisant la commande CREATE PUBLICATION
et peut ensuite être modifiée ou supprimée en utilisant la commande
correspondante.
Les tables individuelles peuvent être ajoutées ou supprimées dynamiquement en
utilisant ALTER
PUBLICATION. Les opérations ADD TABLE et
DROP TABLE sont toutes les deux transactionnelles ;
de ce fait, une table va commencer ou arrêter de répliquer dans le bon
instantané seulement une fois que la transaction a été validée.
A published table must have a replica identity
configured in order to be able to replicate UPDATE
and DELETE 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 identity FULL, which means the entire row
becomes the key. When replica identity FULL 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 identity
FULL should only be used as a fallback if no other
solution is possible.
If a replica identity other than FULL is set on the
publisher side, a replica identity comprising the same or fewer columns
must also be set on the subscriber side.
Tables with a replica identity defined as NOTHING,
DEFAULT without a primary key, or USING
INDEX with a dropped index, cannot support
UPDATE or DELETE operations when
included in a publication replicating these actions. Attempting such
operations will result in an error on the publisher.
INSERT operations can proceed regardless of any replica identity.
See ALTER TABLE...REPLICA IDENTITY
for details on how to set the replica identity.
