[SQL Server] Réplication : fonctionnement de la réplication de snapshot

Ce petit billet offre un aperçu du fonctionnement de la réplication instantanée dite de « snapshot ». Pour une présentation générale de la réplication, vous pouvez aller ici.

Présentation rapide de la réplication de snapshot et scénarii d’utilisation

La réplication de capture instantanée (ou de snapshot), généralement utilisée en guise de prérequis pour les autres types de réplication est plus appropriée quand les modifications de données sont significatives mais occasionnelles. Elle est plus appropriée dans le cas d’une réplication très occasionnelle d’une base de données.

Comment SQL Server gère la réplication de snapshot ?

SQL Server traite, via un ensemble de mécanismes appelés SQL Server Replication Agents, la réplication de snapshot.

Dans le cas de la réplication de snapshot, le Snapshot Agent est l’acteur principal. Le snapshot se réalise en 2 temps : tout d’abord, le Snapshot Agent génère des scripts de suppression/création de tous les articles sur l’abonné, puis les place dans un dossier de snapshot. Ensuite, il génère des fichiers BCP (Bulk-Copy Program) de toutes les données à publier contenues au sein des articles de la base de publication, fichiers qui seront, par la suite, stockés dans le dossier de snapshot. La requête ci-dessous permet de consulter les entrées de chaque fichier BCP généré :

USE distribution
GO
SELECT publisher_database_id,
     xact_seqno,type,
     article_id,
     originator_id,
     command_id,
     partial_command,CAST(command AS NVARCHAR(MAX)) AS command_text,
     command,
     hashkey,
     originator_lsn
FROM MSRepl_commands
GO

Durant le snapshot, le Snapshot Agent pose un verrou partagé sur l’ensemble des articles de la base de publication jusqu’à la fin de la génération des fichiers BCP. Le but d’un tel verrou est de garantir l’intégrité et la consistance transactionnelle des données ce qui, en contrepartie, bloque toute opération de mise-à-jour.

Le schéma ci-après résume le fonctionnement d’une réplication de snapshot :

Le job associé à l’exécution du Snapshot Agent est, par défaut, créé au sein de l’instance de chaque base de publication. Et sa convention de nommage est la suivante : <Serveur>-<Base de publication>-<Publication>-<Numéro>, où <Editeur> est le nom de l’instance accueillant la base de publication, <Publication> le nom de la publication créée durant la configuration de l’éditeur, <Numéro> est un petit chiffre utilisé pour éviter tout conflit de nommage. Cela est valable pour tout autre type de réplication.

Quant au Distributor Agent, son job est créé :

  • Soit sur l’instance de la base de publication (éditeur) si le mode push est utilisé. La convention de nommage devient la suivante : <Editeur>-<Base de publication>-<Publication>-<Abonné>-<Numéro>. Où <Abonné> le nom de l’instance où se trouve la base abonnée.
  • Soit sur l’instance de chaque base abonnée si le mode pull est utilisé. La convention de nommage devient, dans ce cas, <Editeur>-<Base de publication>-<Publication>-<Abonné>-<Base abonnée>-<Numéro>.

Pour aller plus loin…

Dans un prochain billet, nous traiterons de la mise-en-place de la réplication de snapshot.

Publicités

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s