[SQL Server] Un peu de théorie sur le log shipping…

Ce petit billet, comme son titre l’indique, explique brièvement le fonctionnement du log shipping.

Qu’est-ce-que log shipping ?

Le log shipping (envoi ou copie de journaux de transactions) est une solution de haut-disponibilité qui fonctionne à travers l’envoi de journaux de transactions (comme son nom l’indique) d’une base principale vers une base secondaire. Autrement dit, cette solution consiste à maintenir une base de données secondaire en état de restauration permanente de sorte qu’en cas de sinistre on puisse basculer la production sur le serveur de secours qui prend alors la place du serveur principal.

Principes de fonctionnement du log shipping

Pour un log shipping efficace, le serveur principal doit s’y prendre de la façon suivante :

  • Sauvegarde complète de la base de données principale et envoi de ladite sauvegarde sur le serveur secondaire. La restauration sur le serveur secondaire doit être faite en utilisant la clause NORECOVERY afin que la base de données secondaire soit en état d’attente de restauration ou la clause STANDBY si l’on souhaite la laisser en mode veille (ou lecture seule).
  • Sauvegarde transactionnelle des logs et envoi de ceux-ci vers le serveur esclave à intervalles réguliers (i.e., toutes les 2, 3 ou 4 heures) avec restauration de tous les logs sur le serveur secondaire, sauf le dernier log qui doit être restauré avec la clause NORECOVERY.

L’utilisation de ce qu’on appelle un monitor server (ou serveur moniteur) peut permettre de rassembler les informations nécessaires à la levée d’une alerte en cas de mauvais déroulement du log shipping (par exemple, en cas d’ absence de sauvegarde et/ou d’envoi et/ou de restauration de journaux de transactions depuis X secondes, minutes, heures ou jours).


Légende :
IA : instance A contenant la base principale à synchroniser.
IB : instance B contenant la base secondaire.
IM : instance faisant office de serveur moniteur pour les alertes.

Le principal inconvénient du log shipping est qu’en cas de crash du serveur principal, le basculement ne peut se faire que manuellement même s’il est possible d’automatiser ceci au moyen d’un développement particulier. Il faut aussi savoir que plus le serveur secondaire est éloigné du serveur principal, plus les chances qu’il ait des pertes de données lors de l’envoi des fichiers de logs devient élevé.

Pour aller plus loin…

Dans un prochain billet, nous verrons comment mettre en place le log shipping sous SQL Server Management Studio et en T-SQL « pur ».

Publicités

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s