Log Shipping

permet d’automatiser une sauvegarde
de base de données et de la
restaurer sur un serveur différent.
Plusieurs articles de Ron Talmage (voir
l’encadré Autres lectures) couvrent le
log shipping en détail. Donc, nous
n’examinerons pas ici ses mécanismes
internes.
Le log shipping protège contre la
défaillance matérielle par sa résilience.
Il a pour rôle de copier les fichiers de
sauvegarde d’un serveur primaire sur
un serveur secondaire, puis de restaurer
les fichiers sur ce dernier. Le modèle
de base du log shipping est constitué
par un serveur primaire et un
serveur secondaire qui sont indépendants,
ne partageant aucun composant
matériel. Cette configuration supprime
le point unique de défaillance matérielle
présent dans un cluster qui utilise
une matrice de lecteurs partagée.
Le log shipping fournit une redondance
de données nettement supérieure
dans beaucoup plus d’environnements
qu’il n’est possible avec le
failover clustering. Par exemple,
Windows Server 2003 Datacenter
Edition prend en charge un maximum
de huit noeuds dans un cluster. Mais la seule chose qui limite le nombre de
serveurs secondaires que vous pouvez
avoir avec le log shipping est la quantité
d’infrastructure que vous pouvez
gérer. Vous pouvez créer autant de copies
de sauvegarde que vous voulez. Le
log shipping peut aussi fonctionner sur
des distances bien plus longues que le
failover clustering. La plupart des clusters
failover sont limités à  environ une
centaine de kilomètres. Avec le log
shipping, seule la longueur du câble
entre les serveurs primaires et secondaires
limite la dissémination géographique
des serveurs secondaires.
Bien que le log shipping soit un
composant d’une solution haute disponibilité,
il lui manque une fonction
essentielle : un mécanisme permettant
de détecter automatiquement la défaillance
et de déclencher un basculement
vers le serveur secondaire. Le log
shipping a aussi un temps de décalage
pendant le basculement quand toutes
les sauvegardes sont appliquées au serveur
secondaire avant qu’il puisse être
récupéré et rendu disponible. Comme
le log shipping compte sur les copies
des sauvegardes provenant du serveur
primaire, on risque de perdre certaines
transactions engagées si le serveur primaire
subit une défaillance matérielle
complète. Avec le failover clustering,
une fois que SQL Server est revenu online,
les clients peuvent se reconnecter
sans aucun changement dans les
chaînes de connexion. Log shipping
n’a pas cette transparence : les clients
doivent se connecter à  un serveur avec
un nom différent du serveur primaire.
Vous pouvez accéder à  une autre
fonction du log shipping au moyen des
options de restauration utilisées lors
de l’application des sauvegardes des
journaux de transactions suivants. Si
vous utilisez l’option WITH STANDBY
pour la restauration, vous pouvez
rendre le serveur secondaire disponible
pour des activités en lecture
seule. Ce serveur secondaire est un excellent
endroit pour déplacer le reporting
et autres opérations de lecture du
serveur primaire et il procure un niveau
d’évolutivité que ne saurait fournir
un failover cluster.