Réplication

transactionnelle
dans le cas où un Publisher – le
serveur primaire – envoie des données
à  un ou plusieurs Subscribers – les serveurs
secondaires.Le failover clustering fonctionne au
niveau du serveur : il s’assure que tout
le SQL Server est disponible. Log shipping
se situe à  un niveau plus granulaire,
assurant la disponibilité d’une
base de données à  l’intérieur d’un serveur.
Quant à  la réplication, elle atteint
le niveau le plus granulaire : elle assure
la disponibilité transaction par transaction
et peut même fournir la disponibilité
pour un seul sous-ensemble d’une
table dans une base de données. Alors
que le log shipping fonctionne en restaurant
les sauvegardes de journaux de
transactions du serveur primaire sur
un serveur secondaire, la réplication
intervient dans le journal de transactions
pour envoyer des transactions individuelles
à  un serveur secondaire, au
fur et à  mesure qu’elles se produisent.
Grâce à  cette fonction granulaire, la réplication
peut assurer un basculement
extrêmement rapide d’un serveur primaire
à  un secondaire. Dans la plupart
des configurations stables, on peut garder
les données sur un serveur secondaire
à  1 ou 2 secondes d’écart du primaire.
Bien qu’elle puisse atteindre une
latence extrêmement basse, la réplication
n’a pas de mécanisme de planification
qui demande une latence maximale
entre le serveur primaire et
serveur secondaire. Le moteur de
réplication réplique les données et
les applique au serveur secondaire
chaque fois qu’il l’atteint. Bien que le
moteur de réplication parvienne à  délivrer
les données, l’incertitude du délai
de livraison cause le plus de problèmes
en cas de réplication.
Heureusement, le délai de livraison
dépend entièrement des développeurs,
des DBA et autres spécialistes
IT. Vous ne pouvez pas répliquer une
transaction tant qu’elle n’a pas été engagée,
donc les développeurs qui écrivent
de grandes transactions créent
des problèmes de latence dans la réplication,
sur deux fronts. Premièrement,
comme ces transactions longues à  exécuter
ne sont répliquées sur le serveur
secondaire que lorsqu’elles sont complètes,
le secondaire (c’est-à -dire, la
cible de la réplication) prend un net
retard par rapport au primaire.
Deuxièmement, quand une transaction
est engagée, la triple opération : packager la transaction, la transmettre
et l’exécuter sur le serveur secondaire,
prend beaucoup de temps. En outre, la
réplication transactionnelle garantit
que les transactions seront engagées
sur le serveur secondaire exactement
dans le même ordre que sur le
primaire. Comme le moteur de réplication
sérialise toutes les transactions
engagées, toutes les transactions engagées
suivantes se mettront en file d’attente
derrière une grande transaction,
en attendant leur tour de s’exécuter.
Cela peut constituer une grave limitation
et l’impact sur le moteur de
réplication est significatif. Mais la disponibilité
n’en est pas trop affectée.
Les implémentations de réplication
pour la haute disponibilité emploient
généralement au moins trois serveurs.
Le Publisher est le serveur primaire où
les applications envoient toutes les
transactions. Le Subscriber est le serveur
secondaire, qui agit comme un
standby pour le serveur primaire et est
disponible en cas de défaillance de celui-
ci. Le troisième serveur est le
Distributor, dont la seule fonction est
de garantir la livraison des transactions
au serveur secondaire. Dès que les
transactions sont copiées du Publisher
sur le Distributor, celui-ci les délivre au
Subscriber. Ce processus permet à  une
application de basculer immédiatement
sur le serveur secondaire –
même si toutes les transactions n’ont
pas été engagées sur le secondaire –
parce que le Distributor garantit leur livraison.
En général, la manière dont
vous gérez cette latence de disponibilité
des données déterminera la rapidité
avec laquelle vous pouvez basculer
du serveur primaire au secondaire.
Dans des conditions idéales, le clustering
peut accomplir un basculement
en 15 secondes environ, le log shipping
peut accomplir un basculement
en 1 ou 2 minutes environ, mais la réplication
peut donner un basculement
instantané.
Comme le log shipping, la réplication
peut maintenir autant de serveurs
secondaires que nécessaire. La seule limitation
vient de la capacité de traitement,
de la bande passante du réseau,
et de la compétence du gestionnaire
de l’infrastructure. Comme avec le log
shipping, vous pouvez utiliser un serveur
secondaire pour décharger les
opérations de lecture afin d’accroître
l’évolutivité. Le serveur secondaire
reste disponible à  100 % pour des opérations
de lecture même pendant que
le Distributor est en train d’appliquer
des transactions. Il reste disponible
parce que – contrairement aux restaurations
de journaux de transactions sur
lesquels compte le log shipping, qui ne
peuvent pas se produire pendant
qu’un autre utilisateur accède à  la base
de données – le moteur de réplication
émet les mêmes transactions sur le serveur
secondaire que l’application sur
le primaire a émises. De plus, comme
le log shipping, la réplication n’a pas
un point unique de défaillance matérielle
parce qu’elle utilise un serveur
séparé physiquement et elle ne fournit
pas de basculement automatisé. Le
moteur de réplication retraite essentiellement
les transactions sur le serveur
secondaire. Cela a une conséquence
: le moteur de réplication ne
peut pas propager une corruption des
données du serveur primaire au secondaire.
Bien entendu, pas plus que les
deux autres composants de la haute
disponibilité, la réplication ne vous
protègera contre l’erreur utilisateur.
C’est le seul problème de disponibilité
contre lequel la technologie est impuissante.
Il semble donc que la réplication
soit un superbe choix en matière de
haute disponibilité. Mais les choses ne
sont pas aussi simples. Bien que vous
ayez séparé physiquement les composants
matériels, comme la réplication
lie de multiples machines entre elles, la
défaillance d’un serveur peut entraîner
celle du voisin. C’est ce que l’on
appelle une défaillance soft, qui résulte
généralement du journal de transactions
remplissant l’espace disque disponible
et mettant la base de données
offline. L’émission d’une sauvegarde
du journal de transactions ne résout
pas ce problème. Parce que même si
une telle sauvegarde enlève les transactions
engagées du journal, elle ne
supprime pas les transactions sur les
tables répliquées à  partir du journal
jusqu’à  ce qu’elles arrivent au serveur
suivant en amont. Par conséquent, les
transactions répliquées sur le Publisher
ne peuvent pas être enlevées du
journal de transactions tant qu’elles
n’ont pas été écrites correctement sur
le Distributor. Et vous ne pouvez pas
supprimer des transactions du
Distributor tant qu’elles n’ont pas été
écrites correctement sur tous les
Subscribers. Si un Subscriber est défaillant
et s’il reste offline pendant un
long moment, le volume de données
sur le Distributor risque de grossir jusqu’à 
dépasser l’espace disque disponible
et causer la mise offline du
Distributor. A son tour, cette situation
empêche d’enlever les transactions du
journal de transactions sur le
Publisher, jusqu’à  ce qu’elles aient été
écrites sur le Distributor. Si le journal
de transactions se remplit et ne peut
pas s’étendre, le serveur primaire se
met offline. Si vous mettez en oeuvre la
réplication pour obtenir la haute disponibilité,
vous devez surveiller cela
de près et corriger les défaillances rapidement
pour prévenir ce scénario de
défaillances en cascade.