La réplication

SQL Server 2005 propose un puissant modèle de réplication de données. Le processus de réplication permet de dupliquer des informations sur plusieurs serveurs. Ces données sont alors accessibles en lecture ou bien en lecture/écriture (sous certaines conditions) sur le serveur cible du processus de réplication.

La réplication n'est pas un moyen de sauvegarde des données.

Pour expliquer et comprendre la processus de réplication, tel que défini dans SQL Server, il faut définir les 4 termes suivants:

Editeur	Comme dans le monde des journaux, c'est l'éditeur qui détient la source de l'information. Le serveur qui rempli ce rôle est donc celui qui possède la base de données, qui contient les informations à répliquer.
Distributeur	C'est lui qui se charge de synchroniser le contenu présent chez les abonnés, en fonction des informations fournies par l'éditeur. Le serveur qui joue le rôle du distributeur peut être celui qui est l'éditeur ou bien un autre.
Abonné	C'est le "client" de la réplication. Les informations vont donc être dupliquées sur l'abonnée. En fonction du type de réplication choisi, ces données seront accessibles en lecture ou bien lecture/écriture.
Publication	La publication, représente l'unité de base de la réplication. Chaque publication correspond à un ensemble de données et est défini dans une réplication.

Les différents type de réplication

Il existe 4 grands type de réplication:

• Capture instantanée: Quelque soit le type de réplication choisi, une capture instantanée sert toujours de point de départ. La capture instantanée permet de prendre une "photo" exact de la publication afin d'être capable de reproduire cette photo sur les abonnés. La capture instantanée concerne aussi bien les structures que les données. Le résultat de la capture instantanée est stocké sous forme de fichiers sur le serveur de distribution. Les abonnées y accèdent via un partage réseau. Il est possible de refaire régulièrement la capture instantanée. Ce type de réplication convient parfaitement pour des données stables, par exemple un catalogue de produits. Ce type de capture est également adapté si les mises à jour sont rares et affecte un grand nombre de lignes. Par exemple, une fois par an le catalogue est mi à jour. Certains articles disparaissent, d'autres apparaissent et de nombreux prix sont mis à jour.
• Transactionnelle: Avec ce type de réplication, lorsque les données sont modifiée, alors les informations sont reportées dans la base de distribution. Ce mécanisme ne concerne que les données sujettes à une publication. C'est l'agent de lecture du journal qui se charge de reporter les modifications dans la base de distribution. Les abonnées se connectent régulièrement à la base de distribution pour récupérer l'ensemble des modifications. Au départ de ce type de réplication, on trouve une capture instantanée.
• Transactionnelle avec abonnements pouvant être mis à jour: Il s'agit d'une réplication transactionnelle classique, avec la possibilité pour les abonnées de mettre à jour les informations stockées localement. Cette mise à jour locale est accompagnée d'une mise à jour des informations sur l'éditeur. C'est cette mise à jour sur l'éditeur qui permet de reporter les modifications sur toutes les bases abonnées.
• Fusion: Dans ce type de transaction, tous les participants travaillent au départ avec le même jeu d'information, issue d'une capture instantanée, puis chaque site évolue de façon autonome. L'objectif de la réplication est alors de consolider les informations afin que chaque participant travail avec les mêmes données.

La mise en place d'une réplication

Configurer SQL Server Agent

Tous les services et les différents agents de réplications sont gérés par le service SQL Server Agent. C'est donc par l'intermédiaire du contexte de sécurité de ce compte, que l'abonné va accéder au partage de capture instantanée. Le service SQL Server Agent doit donc s'exécuter dans le contexte d'un compte d'utilisateur du domaine. Si cela n'est pas possible, il est alors nécessaire que le service s'exécute dans le contexte d'un compte d'utilisateur local. Ce même compte, avec le même mot de passe sera défini sur tous les postes qui participent à la réplication.

Les propriétés du compte Windows sont les suivantes:

Ouvrir une session en tant que service	SeServiceLogonRight
Ouvrir une session en tant que tâche	SeBatchLogonRight
Remplacer un jeton au niveau processus	SeAssignPrimaryTokenPrivilege
Outrepasser le contrôle de parcours	SeChangeNotifyPrivilege
Changer les quotas de mémoire d'un processus	SeIncreaseQuotaPrivilege

Si le serveur s'exécute sous Windows 2000 il est alors nécessaire d'accorder en plus le privilège suivant:

Agir dans le cadre du système d'exploitation(Windows 2000)

SeTcbPrivilege

Bien entendu le compte d'utilisateur ne doit pas changer de mot de passe à la première ouverture de session, et le mot de passe n'expire jamais.

Configurer un distributeur

L'opération se déroule depuis SQL Server Management Studio.

L'assistant demande de spécifier si le serveur joue également le rôle de Distributeur.

Si c'est le cas, la base de données de distribution va être créée ainsi qu'un partage pour y déposer les capture instantanées. Les captures instantanées sont habituellement déposées dans le dossier repldata (C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\repldata). Il est donc nécessaire de partager le dossier pour que les abonnés puissent accéder facilement à ces informations. Dans le cas contraire, seul les abonnements poussés depuis le distributeur seront possible car les abonnées n'auront pas accès à cette ressource.

L'assistant demande alors de définir le nom et l'emplacement des fichiers pour la base de données de distribution.

L'assistant, permet alors de configurer le distributeur afin d'autoriser une ou plusieurs instances SQL Server à utiliser ce distributeur.

 

L'assistant est maintenant presque fini. La dernière question, concerne le type de travail effectuée à la fin de l'assistant: une mise à niveau immédiate de l'instance et/ou la génération de scripts afin d'être capable de rejouer le processus plus tard.

Définir une publication

L'étape suivante consiste à définir une ou plusieurs publications sur l'un des serveurs définis en tant qu'éditeur lors de l'étape précédente.

Il est possible de définir une nouvelle publication depuis l'explorateur d'objet en sélectionnant Nouvelle publication dans le menu contextuel associée au nœud Réplication - Publications locales comme illustré ci dessous.

En effectuent ce choix, un assistant est exécuté pour permettre de définir simplement les éléments qui participent à la publication et comment ils y participent (le type de réplication). La première étape de l'assistant  consiste à choisir la base de données qui contient les objets et les données à publier. Dans l'exemple utilisé ici, c'est la base Club qui va héberger la publication.

Il est ensuite nécessaire de choisir le type de réplication qui va être utilisé pour la publication en cours de définition. Dans le cas présent c'est une réplication transactionnelle qui va être sélectionnée.

L'assistant demande alors de spécifier le ou les objets qui vont participer à cette publication. Ici ce sont les tables Individus et Adhesions qui participent à la publication. Pour chaque table il est possible de préciser si les colonnes participent bien à la publication. La bouton Propriétés de l'article permet de spécifier plus finement le comportement de l'article au sein de la publication

Il est alors possible de filtrer les données à partir des tables sélectionnées. Il s'agit d'un filtre vertical. Le filtre est défini pour préciser les lignes qui ne participent pas à la publication.

La mise en place des abonnements s'appuie sur une capture instantanée. Cette capture peut être réalisée à la fin de l'exécution de l'assistant. Elle peut également être planifiée de façon à permettre une intégration rapide des abonnés même si le volume de données modifiées est important depuis la mise en place de la publication. Dans l'exemple présenté ci dessous, la capture instantanée à lieu immédiatement et elle est planifiée pour être exécutée une fois par mois.

C'est maintenant des considérations de sécurité qui sont abordées afin de définir le compte de sécurité utilisé par les différents agents qui participent à la réplication

Enfin l'assistant demande si la publication doit être créé immédiatement et si elle doit être accompagné de la génération de script Tansact SQL.

Un dernier écran permet de définir le nom de la réplication. La réplication est alors créée. Après cette étape elle est visible depuis SQL Server Management Studio au niveau des publications locales.

A partir de SQL Server Management, il est possible de modifier une publication et de revenir sur les différents choix réalisés à partir de l'assistant lors de sa création.

Abonner des instances SQL Server

Une façon simple de mettre en place les abonnements, mais ce n'est pas la seule, consiste à inscrire tous les serveurs qui doivent être abonné dans la console SQL Server Management Studio avec laquelle on travail. Puis depuis le serveur qui joue le rôle de distributeur, il est possible de pousser des abonnements. Cette opération est possible en sélectionnant nouveaux abonnements dans le menu contextuel associé à la publication. Ce type d'abonnement est dit poussé car c'est le distributeur qui prend l'initiative d'envoyer cet abonnement sur le serveur distant.

Il est également possible de tirer un abonnent depuis le server abonné en sélectionnant nouveaux abonnements dans le menu contextuel du nœud Réplication - Abonnements locaux depuis l'explorateur d'objets. L'assistant permet alors de localiser une publication en se connectant au serveur distributeur.

Dans le cas d'un abonnement poussé, l'assistant demande à sélectionner la publication concernée par cet abonnement, Puis il demande sur quel server l'agent de réplication va s'exécuter. C'est l'emplacement de cet agent qui va réellement déterminer si l'abonnent est poussé (l'agent s'exécute sur le serveur de distribution) ou bien tiré (l'agent est exécuté sur l'abonné).

L'assistant demande alors de sélectionner le ou les serveurs abonnés. Puis pour chaque abonné, il est nécessaire de précisé comment l'agent de distribution être capable de se connecter, et le contexte de sécurité utilisé pour se connecter au distributeur et à l'abonné.

Enfin l'assistant va offrir la possibilité de planifier l'exécution du service de réplication ainsi que le moment où la capture instantanée va être restituée sur le serveur abonné.

L'abonnement est alors complètement défini. Il est possible de l'enregistrer immédiatement et/ou sous forme de script. Après initialasation du serveur abonnée, les données sont répliquées de l'éditeur vers l'abonné en fonction de la planification mise en place.