Comment fonctionnent les abonnements pouvant être mis à jour
Les abonnements pouvant être mis à jour pour la réplication transactionnelle autorisent les abonnés à répliquer les modifications sur le serveur de publication. Des déclencheurs sont ajoutés aux tables publiées dans la base de données d'abonnement, et lorsqu'une modification est effectuée sur l'Abonné, le déclencheur s'exécute :
Pour la mise à jour immédiate des abonnements, la modification est directement propagée sur le serveur de publication et appliquée à l'aide de Microsoft Distributed Transaction Coordinator (MSDTC).
Pour la mise à jour en attente des abonnements, la modification est d'abord propagée sur une file d'attente, puis appliquée sur le serveur de publication par l'Agent de lecture de la file d'attente.
Les modifications effectuées sur le serveur de publication sont répliquées aux abonnés de la même façon que les publications transactionnelles avec les abonnés en lecture seule. Pour plus d'informations, consultez Fonctionnement de la réplication transactionnelle.
Mise à jour immédiate
La mise à jour immédiate des abonnements utilise les composants suivants :
Une colonne de suivi pour chaque table publiée
Lorsqu'une table est publiée dans une publication autorisant les abonnements pouvant être mis à jour, la colonne msrepl_tran_version est ajoutée à la table. Cette colonne est utilisée pour le suivi des modifications et la détection des conflits. Les conflits se produisent, dans la mise à jour immédiate, si l'Abonné met à jour une copie obsolète des données.
MSTDC
Pour chaque modification effectuée sur un abonné, MSDTC gère l'opération de validation en deux phases entre le serveur de publication et l'Abonné validant la modification. Cette approche ne présente pas les contraintes de disponibilité de la validation en deux phases avec tous les sites participants, puisque seul le serveur de publication doit être disponible. Une fois que la modification est effectuée sur le serveur de publication à l'aide de la validation en deux phases, elle est répliquée aux autres abonnés par l'Agent de distribution.
Des déclencheurs sur les tables de la base de données d'abonnement
Les déclencheurs d'insertion, de mise à jour et de suppression sont ajoutés sur chaque table publiée dans la base de données d'abonnement. Les déclencheurs sont créés à l'aide du modificateur NOT FOR REPLICATION de l'instruction CREATE TRIGGER pour que les modifications appliquées par l'Agent de distribution ne les activent pas. Pour plus d'informations, consultez Contrôle des contraintes, des identités et des déclencheurs avec l'option NOT FOR REPLICATION.
Pour la mise à jour immédiate des abonnements, les déclencheurs gèrent également les valeurs des colonnes identity et timestamp sur l'Abonné. Les valeurs sont générées sur le serveur de publication pour ces types de colonnes et propagées sur l'Abonné dans le cadre de l'opération de validation en deux phases.
Des procédures stockées
Lorsque vous créez une publication et l'activez pour la mise à jour immédiate des abonnements, des procédures d'insertion, de mise à jour et de suppression sont créées pour chaque table publiée dans la base de données de publication. Lorsqu'une modification se produit sur l'Abonné, un déclencheur de réplication émet un appel de procédure distante via MSDTC à la procédure stockée appropriée sur le serveur de publication, laquelle applique ensuite la modification.
Les procédures stockées du serveur de publication n'appliquent des modifications que si elles ne provoquent pas de conflits avec les modifications apportées sur le serveur de publication après que l'Abonné ait reçu sa copie des lignes modifiées. Si un conflit est détecté, la transaction est rejetée et annulée sur le serveur de publication et sur l'Abonné.
L'illustration suivante montre les principaux composants utilisés dans une topologie incluant la mise à jour immédiate des abonnements.
.gif "Composants et flux de données de mise à jour immédiate")
Une modification effectuée sur l'Abonné est capturée par un déclencheur sur la table d'abonnement.
Le déclencheur appelle via MSDTC la procédure stockée appropriée sur le serveur de publication.
La procédure stockée effectue l'insertion, la mise à jour ou la suppression à moins qu'il existe un conflit. S'il existe un conflit, la modification est annulée sur le serveur de publication et sur l'Abonné.
Les modifications effectuées sur le serveur de publication, résultant de modifications répliquées à partir d'un abonné, sont propagées à tous les autres abonnés selon la planification de l'Agent de distribution.
Mise à jour en attente
La mise à jour en attente des abonnements utilise les composants suivants :
Une colonne de suivi pour chaque table publiée
Lorsqu'une table est publiée dans une publication autorisant les abonnements pouvant être mis à jour, la colonne msrepl_tran_version est ajoutée à la table. Cette colonne est utilisée pour le suivi des modifications et la détection des conflits.
Des déclencheurs sur les tables de la base de données d'abonnement
Les déclencheurs d'insertion, de mise à jour et de suppression sont ajoutés sur chaque table publiée dans la base de données d'abonnement. Les déclencheurs sont créés à l'aide du modificateur NOT FOR REPLICATION de l'instruction CREATE TRIGGER pour que les modifications appliquées par l'Agent de distribution ne les activent pas. Pour plus d'informations, consultez Contrôle des contraintes, des identités et des déclencheurs avec l'option NOT FOR REPLICATION.
Des procédures stockées
Lorsque vous créez une publication et l'activez pour la mise à jour en attente des abonnements, des procédures d'insertion, de mise à jour et de suppression sont créées pour chaque table publiée dans la base de données de publication.
Ces procédures stockées, appelées par l'Agent de lecture de la file d'attente, permettent d'appliquer les transactions sur le serveur de publication, de détecter les conflits et, si nécessaire, de générer des commandes de compensation qui seront déposées dans la base de données de distribution puis remises à l'abonné.
Une procédure stockée permettant de consigner les informations relatives aux conflits sur le serveur de publication (et, facultativement, de communiquer ces informations aux abonnés concernés) est également créée sur le serveur de publication. Elle est appelée par l'Agent de lecture de la file d'attente si un conflit est détecté.
Microsoft File d'attente Microsoft SQL Server
Chaque base de données d'abonnement contient la table système MSreplication_queue, qui stocke les modifications provenant de l'Abonné.
Agent de lecture de la file d'attente SQL Server
L'Agent de lecture de la file d'attente lit les modifications à partir de MSreplication_queue et les applique au serveur de publication. Pour plus d'informations, consultez Agent de lecture de la file d'attente de réplication.
L'illustration suivante montre les principaux composants utilisés dans une topologie incluant la mise à jour en attente des abonnements.
.gif "Composants et flux de données de mise à jour en file d'attente")
Les mises à jour effectuées sur l'abonné sont capturées par des déclencheurs définis sur les tables d'abonnements. Les déclencheurs stockent ces mises à jour dans MSreplication_queue.
L'Agent de lecture de la file d'attente lit à partir de MSreplication_queue, puis applique les transactions de file d'attente à la publication appropriée à l'aide de procédures stockées de réplication.
Lors de l'application des transactions en attente, les conflits éventuels sont détectés et résolus selon une stratégie de résolution de conflits définie au moment de la création de la publication. Par conséquent, des commandes de compensation peuvent être générées pour restaurer une transaction sur un abonné à l'aide du processus standard de distribution de la réplication transactionnelle (ces commandes ne sont envoyées qu'à l'Abonné ayant causé le conflit). Pour plus d'informations, consultez Détection et résolution des conflits de mise à jour en attente.
Les modifications effectuées sur le serveur de publication, résultant de modifications répliquées à partir d'un abonné, sont propagées à tous les autres abonnés selon la planification de l'Agent de distribution.