Réplication bidirectionnelle avec SQL Server 7.0

Microsoft utilise une métaphore éditeur-abonné pour décrire le processus de réplication
de SQL Server. Les éditeurs sont des serveurs qui soumettent leurs données à  la
réplication. Les abonnés sont des serveurs vers lesquels SQL Server réplique les
données. Notez que tout éditeur peut agir simultanément comme abonné. SQL Server
génère des publications sur un éditeur, lesquelles peuvent contenir un ou plusieurs
articles. Un article peut représenter une table ou un sous-ensemble de table.

Dès lors, pour créer des abonnements il faut sélectionner les publications que
l’éditeur doit répliquer vers les abonnés. Chaque abonnement peut contenir un
ou plusieurs articles qui pour être répliqués, doivent faire l’objet d’un abonnement.
La dernière composante du puzzle est le distributeur (c’est-à -dire le serveur
qui assure le suivi des données et des transactions à  répliquer). Remarquez que
le distributeur peut représenter le serveur qui joue le rôle de l’éditeur ou un
serveur distinct.

SQL Server 7.0 supporte trois types de réplications : par capture instantanée,
transactionnelle et par fusion. La réplication par capture instantanée transfère
une image instantanée des données (une copie des données à  un instant donné) d’une
base de données vers une autre. Ce type de réplication génère une très faible
surcharge de travail sur les serveurs éditeur et distributeur, mais elle ne procure
pas un très haut niveau de cohérence des données entre les différentes parties
impliquées dans le processus de réplication, car les bases de données éditeur
et abonné ne sont pas maintenues en phase.
Ainsi, la réplication par capture instantanée convient plutôt aux situations où
il n’est pas nécessaire que les données soient identiques à  la seconde près.

En revanche, avec la réplication transactionnelle, plusieurs processus surveillent
de façon continue les modifications apportées sur l’éditeur et périodiquement
répliquent ces modifications vers les abonnés. Avec SQL Server 7.0, il est possible
de configurer la réplication pour qu’elle surveille également les bases de données
de l’abonné et qu’elle réplique les modifications sur l’éditeur. Chez Microsoft,
cette fonctionnalité est connue sous le nom de réplication avec mise à  jour immédiate
des abonnements. La réplication transactionnelle convient tout particulièrement
aux situations dans lesquelles les données doivent être synchronisées de façon
continue entre les serveurs éditeur et abonné.

SQL Server 7.0 supporte également la toute nouvelle réplication par fusion, qui
permet de fusionner des données provenant de plusieurs bases de données situées
sur différents serveurs vers un serveur central. Ce type de réplication convient
parfaitement aux environnements dans lesquels un serveur central agit en tant
que référentiel principal d’une entreprise, ce dernier devant être régulièrement
synchronisé avec tous les abonnés. Les abonnés prenant part à  une réplication
par fusion peuvent également modifier les données. Si l’éditeur et un abonné modifient
les mêmes données au même moment, un algorithme de détection des conflits détermine
la version qui prévaudra.

Lorsque l’on envisage de mettre en oeuvre des solutions de réplication, il faut
trouver un juste milieu entre la latence de la réplication et l’intégrité des
données. Avec une latence minimal (c’est-à -dire si on réplique les transactions
dès que SQL Server les valide sur l’éditeur) on augmente la surcharge de travail
à  la fois sur l’éditeur et le distributeur.
Pour gérer cette charge, il peut être judicieux d’installer un serveur distinct
en guise de distributeur. Cependant, si on tolère un certain délai entre la validation
de la transaction et la réplication, la surcharge sera plus acceptable, mais on
va risquer de ne pas avoir des données synchronisées à  la seconde sur les abonnés.
Imaginez par exemple que le siège d’une banque utilise SQL Server pour générer
des rapports quotidiens pour la direction et que les agences de cette même banque
utilisent SQL Server pour gérer les transactions des clients sur les distributeurs
automatiques de billets. Un certain décalage dans la réplication des transactions
entre le siège et les agences peut être toléré.
En revanche, il faut répliquer le retrait d’argent en espèces dans une agence
sur les autres serveurs de la banque immédiatement.

Dans l’exemple présenté ci-dessus, il est recommandé d’investir dans un serveur
distributeur distinct pour propager les résultats des transactions de chaque éditeur
(chaque serveur d’agence) vers les abonnés (les serveurs des autres agences).
Avec SQL Server 7.0, on peut mettre en place un distributeur central puis configurer
toutes les agences comme des éditeurs implémentant la fonction de réplication
avec mise à  jour immédiate des abonnements. Avec une telle configuration, toutes
les agences de la banque disposeront du nouveau solde de tous les comptes à  la
seconde près, quel que soit le lieu du retrait d’argent. Pour sa part, le siège
sera configuré comme un abonné qui récupère les abonnements de toutes les agences
à  la fin de la journée. Les cadres dirigeants qui n’ont pas forcément besoin des
informations les plus récentes sur les comptes de tous les clients reçoivent alors
des rapports d’activité quotidiens le matin.