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 31.3.)
Une table publiée doit avoir une identité de réplication
configurée pour être capable de répliquer des opérations
UPDATE
et DELETE
, pour que les lignes
appropriées à modifier ou supprimer puissent être identifiées du côté de
l'abonné. Par défaut, il s'agit de la clé primaire, si elle existe. Un autre
index d'unicité (avec quelques prérequis supplémentaires) peut aussi être
configuré du côté de l'abonné. Si la table n'a pas de clé convenable, alors
elle peut être configurée pour l'identité de réplicat FULL
,
ce qui signifie que la ligne entière devient la clé.
Lorsque l'identité de réplicat est spécifiée à FULL
,
des index peuvent être utilisés du côté de l'abonné pour rechercher des lignes.
Ces index candidats doivent être de type btree, non-partiels, et le champ d'index le plus à gauche
doit être une colonne (pas une expression) qui référencie la colonne de la table publiée. Ces
restrictions sur les propriétés non-unique de l'index correspondent à certaines des restrictions
renforcées par des clés primaires. S'il n'y a pas d'index approprié, la recherche côté abonné
peut être très peu efficace, par conséquent l'identité de réplicat FULL
devrait seulement être utilisée comme solution de repli si aucune autre solution n'est
disponible. Si une identité de réplication est différente de
FULL
du côté du publieur, une identité de réplication
comprenant les mêmes colonnes, ou moins de colonnes, peut aussi être
configuré du côté de l'abonné. Voir REPLICA IDENTITY
pour les détails sur la
configuration de l'identité de réplication. Si une table sans identité de
réplication est ajoutée à une publication qui réplique les opérations
UPDATE
ou DELETE
, alors les opérations
UPDATE
ou DELETE
suivantes causeront une
erreur sur le publieur. Les opérations INSERT
peuvent se
réaliser quelle que soit l'identité de réplication.
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.