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.
Une table publiée doit avoir une identité de réplicat
configurée pour être capable de répliquer les opérations
UPDATE et DELETE, pour que les lignes
ciblées par les mises à jour ou suppressions puissent être identifiées sur
l'abonné.
Par défaut, il s'agit de la clé primaire, s'il en existe une. Une contrainte
d'unicité (avec quelques prérequis supplémentaires) peut aussi être
configurée comme une identité de réplicat. Si la table n'a pas de contrainte
convenable, alors son identité de réplicat peut être configurée à
FULL, ce qui signifie que la ligne entière devient la
clé. Quand l'identité de réplicat FULL est indiquée,
les index peuvent être utilisés sur le côté abonné pour rechercher les
lignes. Les index candidats doivent être des btree ou des hash, non
partiels, et le champ le plus à gauche doit être une colonne (pas une
expression) qui référence la colonne de la table publiée. Ces restrictions
sur les propriétés de l'index (sans unicité) adhèrent à certaines des
restrictions posées sur les clés primaires. Si aucun index ne convient,
la recherche sur l'abonné peut être très inefficace, donc l'identité de
réplicat FULL doit seulement être utilisée si aucune
autre solution n'est possible.
Si une identité de réplicat autre que FULL est configuré
sur le côté publieur, une identité de réplicat comprenant les mêmes colonnes
ou moins de colonnes doit être configuré sur le côté abonné.
Les tables avec une identité de réplicat définie comme
NOTHING, DEFAULT sans une clé
primaire, ou USING INDEX avec une clé supprimée, ne
peuvent pas prendre en compte des opérations UPDATE ou
DELETE lorsqu'elles sont inclus dans une publication
répliquant ces actions. Tenter de telles opérations résultera en une erreur
sur le publieur.
Les opérations INSERT peuvent s'exécuter quelque soit
l'identité de réplicat.
Voir ALTER
TABLE...REPLICA IDENTITY pour des détails sur la
configuration de l'identité de réplicat.
