> Data > Réplication bidirectionnelle avec SQL Server 7.0

Réplication bidirectionnelle avec SQL Server 7.0

Data - Par iTPro.fr - Publié le 24 juin 2010
email

par Baya Pavliashvili
Les éditeurs convertis en abonnés et les abonnés convertis à  leur tour en éditeurs
Les fonctions avancées de réplication de SQL Server permettent de synchroniser les données de plusieurs bases de données, que celles-ci résident sur le même serveur ou non. Mais pourquoi pas simplement sauvegarder les bases de données et les restaurer ensuite sur un autre serveur, ou utiliser DTS (Data Transformation Services) pour transférer les tables et données ? Si on travaille sur des bases de données accessibles uniquement en lecture, ces techniques conviennent parfaitement. Mais qu'en est-il si on a une base de données transactionnelle (OLTP) de grande taille (100 Go ou plus) gérant une centaine de transactions ou plus par minute ? Ou alors, que faire si on a plus de 1.000 utilisateurs exécutant des instructions Select, Insert, Update et Delete au moins 8 heures par jour ? Dans ce contexte, effectuer des sauvegardes suivies de restaurations toutes les 10 minutes (ce qui aurait pour effet de verrouiller les tables et déclencher des appels d'utilisateurs irrités) est inacceptable. En outre, l'utilisation de DTS ou de bcp (bulk copy program) pour transférer autant d'informations à  chaque fois que l'on souhaite synchroniser des bases de données n'est pas viable ; le transfert nécessiterait beaucoup trop de temps.

Même si la réplication n'accélère pas le transfert des données, elle permet cependant, d'effectuer ce dernier d'un serveur à  un autre en une seule opération, puis de répercuter les modifications sur les autres bases de données. En d'autres termes, la réplication peut représenter la solution idéale pour transférer des données si on recherche un juste milieu entre la propagation des données sur différentes machines et la disponibilité de ces mêmes données.

SQL Server 7.0 passe à  la vitesse supérieure en matière de réplication et de facilité d'emploi

SQL Server 6.0 a apporté le support de la réplication, et SQL Server 6.5 a rajouté des améliorations mineures. Pour sa part, SQL Server 7.0 passe à  la vitesse supérieure en matière de réplication et de facilité d'emploi. En effet, SQL Server 7.0 va bien au delà  d'une photographie instantanée des données et de la réplication transactionnelle standard pour supporter la réplication bidirectionnelle (ou un abonnement avec mise à  jour instantanée) et la réplication par fusion. Cette version permet également de répliquer des données de et vers des plates-formes non SQL. De plus, SQL Server 7.0 automatise toutes les tâches de réplication, permettant ainsi aux administrateurs de configurer et d'administrer la réplication à  l'aide d'assistants, sans écrire une seule procédure cataloguée. A travers les assistants de réplication, il est même possible de paramétrer SQL Server de manière à  écrire des tâches de nettoyage et d'informer les administrateurs des éventuelles erreurs par courrier électronique ou pager. Passons en revue les assistants de SQL Server 7.0 en vue de configurer un exemple de solution de réplication avec mise à  jour immédiate. Examinons ensuite, l'action de SQL Server en coulisses pour implémenter cette solution et pour finir, testons la solution proposée.

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.

Téléchargez gratuitement cette ressource

HP Elite Slice G2 : optimisez la collaboration… et votre budget !

HP Elite Slice G2 : optimisez la collaboration… et votre budget !

Téléchargez cette étude Forrester et découvrez comment booster la collaboration tout en dégageant un excellent R.O.I grâce au système de vidéoconférence HP Elite Slice G2 avec Microsoft Teams !

Data - Par iTPro.fr - Publié le 24 juin 2010