EXEC sp_help_log_shipping_monitor_primary N'nom du serveur primaire', N'nom de la base';Log Shipping
Solution de warm standby basée sur les sauvegardes de journaux de transactions
3 minutes à lire
Principes du Log Shipping
Le log shipping met en place une stratégie de sauvegarde de journaux de transactions, créée à l’aide d’un assistant, et prise en charge par des tâches planifiées, qui utilisent un exécutable externe (logshhip.exe). Le scripting s’effectue à l’aide de procédures stockées système.
Cela permet de disposer d’un ou de plusieurs serveurs en warm standby, par exemple pour une stratégie de PRA distant.
La technologie est ancienne, et peu mise à jour au fil des versions. Elle est encore beaucoup utilisée dans les PME, elle est facile à mettre en place et fonctionne en édition Standard.
Parmi ses avantages :
Génération intégrée de sauvegardes de journaux
Restauration des sauvegardes planifiées, avec un délai paramétrable
Secondaire en lecture en édition standard
… fonctionne en édition standard
Le secondaire peut être ouvert en lecture, en configurant le secondaire en standby. Mais il faut déconnecter les sessions à chaque restauration planifiée.
Il n’y a ni basculement automatique en cas de défaillance, ni redirection automatique des connexions clientes. Ce dernier point peut être simplifié par l’utilisation du DNS.
En cas de défaillance, on perd possiblement toutes les modifications effectuées sur la base principale après la dernière sauvegarde de journal de transactions effectuée dans le cadre du log shipping.
Prérequis
La base doit être en mode de récupération complet.
Un partage doit être visible des deux machines. Les sauvegardes de journaux y seront déposées par le primaire. Les secondaires viendront y chercher les sauvegardes pour les copier sur leur disque local.
Serveur de monitoring
Vous pouvez indiquer dans la configuration un serveur de surveillance pour le log shipping. Les historiques des différents travaux lui seront envoyés. Cela permet aussi de centraliser les alertes.
Sans lui, des alertes sont placées sur le primaire et les secondaires.
Des tables de monitoring sont maintenues dans la base de données système msdb : log_shipping_monitor_*.
Des procédures stockées sont aussi présentes dans msdb : sp_help_log_shipping_*.
Vous trouvez dans SSMS un rapport de log shipping qui utilise ces objets, dans les rapports de l’instance.
Mise en œuvre
Effectuer un basculement planifié
Synchronisez les secondaires : copiez les sauvegardes qui ne le sont pas encore, appliquez les restaurations.
Lancer une sauvegarde de journal manuelle sur le primaire avec l’option NORECOVERY et appliquez-la sur les secondaires.
Choisissez un secondaire et restaurez la dernière sauvegarde avec l’option RECOVERY.
Redirigez les clients.
Intervertir les rôles (switch over)
Effectuez un basculement manuel.
Désactivez le travail de sauvegarde sur le primaire.
Reconfigurez le log shipping avec l’assistant depuis le nouveau primaire.
Mettre à jour le monitoring.
master.dbo.sp_change_log_shipping_secondary_database
master.dbo.sp_change_log_shipping_primary_database
Métadonnées et diagnostic
Vous trouvez une requête de métadonnées à l’adresse suivante : https://github.com/rudi-bruchez/tsql-scripts/blob/master/hadr/log-shipping-metadata.sql.
Exécutez la procédure stockée suivante pour superviser le log shipping. Vous devez être dans le contexte de master.
Problèmes courants
Changement de nom du serveur SQL
Les travaux de log shipping maintiennent le nom du serveur. Si vous changez ce nom, il faut modifier à la main des travaux de log shipping, en entrant dans les travaux de log shipping et en changeant le nom du serveur dans la ligne de commande de l’exécutable de log shipping.
Pour que le monitoring fonction, vous devez aussi changer la configuration à la main dans la table msdb.dbo.log_shipping_primary_databases.
Si vous recréer des envois de journaux sur vos bases, il faut mettre à jour la vieille variable @@SERVERNAME :
SELECT @@SERVERNAME;Si le résultat ne correspond pas au nom de votre machine, exécutez les commandes suivantes.
EXEC sp_dropserver 'nom ancien';
GO
EXEC sp_addserver 'nom nouveau', LOCAL;Il faut redémarrer l’instance pour que ce changement de nom soit pris en compte.