Un processus de « Log Shipping » automatisé dans le cadre d’un PRA

Le concept assez ancien de « Log Shipping » (littéralement journaux naviguant) permet à peu de frais de construire un serveur de secours asynchrone à reprise manuelle. Il est basé sur l’envoi régulier et continu des copies des journaux de transaction générés par la sauvegarde transactionnelle.

La mécanique

Elle se décompose en trois parties :

  • La génération régulière de sauvegardes des journaux de transactions, que l’on effectuera par le biais de l’Agent SQL et à condition que les bases visées soit en mode de journalisation complète (FULL RECOVERY).
  • le déplacement des fichiers de sauvegarde du serveur source au serveur cible, par le biais d’un mécanisme propre au système d’exploitation ou bien à l’aide d’un outil tierce (Robocopy par exemple).
  • La restauration des bases à partir de ces sauvegardes transactionnelles, à condition de mettre ces bases en mode d’attente (NORECOVERY).

Quelques rappels

Pour générer des fichiers de sauvegarde transactionnelle, il suffit d’utiliser la commande Transact SQL :    

Par convention, on utilise l’extension .TRN pour les sauvegardes transactionnelles.

Pour restaurer une base à partir des sauvegardes transactionnelles, il faut :

  • commencer par restaurer le plus récent fichier de la sauvegarde complète de la base, en mode NORECOVERY (la base est alors inaccessible mais présente à l’état de « restauration »)

Ceci se fait à l’aide de la commande :     

  • compléter la base en restaurant, dans l’ordre, les fichiers de sauvegarde transactionnelle en mode NORECOVERY (la base se trouve alors encore en état de restauration).

Ceci se fait à l’aide de la commande :

Le processus devant fonctionner en continu, la base est toujours inaccessible par ce que présente à l’état de restauration.

Pour rendre la base à l’état de production il suffit de restaurer la dernière sauvegarde transactionnelle avec l’option RECOVERY :

Notez que le mot clef RECOVERY n’est pas obligatoire car à défaut.

Le journal de transaction est constitué de segments identifiés par des nombres binaires appelés Log Segment Number (LSN) qui se suivent. Ainsi pour pouvoir reconstituer toutes les transactions d’une base, il faut que ces LSN se recoupent entre la précédente restauration transactionnelle effectuée et la nouvelle à passer.

Toute rupture dans la chaine des segments entraine l’impossibilité de reconstituer la base.

Il faut donc faire très attention à veiller à la continuité de la chaine des sauvegardes transactionnelle qui doit donc être sans oubli et sans trou. Par exemple une sauvegarde complète inopinée casserait cette belle mécanique (sauf si elle est effectuée avec l’option COPY_ONLY).

Quelques subtilités

Si votre base est en état de restauration, il est possible de la basculer en état de production par une simple commande :

Mais dans ce cas vous ne pourrez plus la compléter avec de nouvelles sauvegardes transactionnelles puisque, à l’état de production, son contenu a déjà divergé de la base d’origine. En effet, une transaction la mettant en mode de production a été journalisée à l’intérieur de la base cassant ainsi la continuité des segments transactionnels…

Toujours en état de restauration, il est possible de rendre votre base accessible en lecture seulement et dans un statut permettant de la remettre en état de restauration afin de redémarrer le processus de log shipping. Ceci se fait à l’aide de la commande :

Le fichier « FichierUndo.bak » est un journal parallèle utilisé pour stocker temporairement les données des transactions non encore validées, que le moteur « défait » afin de permettre la lecture de toutes les tables (les verrous en cours étant abandonnés).

Notez que la base se place en état de veille avec lecture seule. Les données sont alors accessibles pour tous types de lectures (vues, requêtes, fonctions, procédures…).

Si la base est en état de restauration avec lecture seulement, alors il est possible de revenir en mode de restauration pour reprendre la continuité du processus de « log shipping » à l’aide de la commande :

La solution d’automatisation

J’ai automatisé une telle solution pour l’un de mes clients à l’aide de deux tables et cinq procédures, le tout figurant dans la base msdb, dans des schémas spécifiques :

  • _MNT  : pour la maintenance, dont la sauvegarde (côté source)…
  • LOG_SHIPPEMENT  pour tous les objets du « log shipping » (côté cible)

Côté source

Une seule procédure, qui effectue toutes les sauvegardes :

Côté cible

Deux tables chacune dotée d’un déclencheur…

La première (LOG_SHIPPEMENT.T_SOURCE_DATABASE_SDB) liste les bases à « log shipper » avec les paramètres suivants :

  • SDB_DB_NAME : le nom réel de la base
  • SDB_SOURCE_SERVER : nom du serveur source dans lequel le caractère \ a été remplacé par un _
  • SDB_SOURCE_DATABASE : nom corrigé de la base (les caractères illicite doivent avoir été remplacé par _
  • SDB_PATH_TO_BACKUPS : chemin du stockage des fichiers de sauvegarde
  • SDB_LAST_RESTORED_BACKFILE : nom du fichier de la dernière sauvegarde restaurée
  • SDB_LAST_DATETIME_BACKFILE : dateheure de la dernière sauvegarde restaurée
  • SDB_LAST_RESTORE_COMMAND : code Transact SQL de la dernière sauvegarde restaurée
  • SDB_LAST_STANDBY_FILE : nom du fichier des transactions abandonnées par le STANDBY

La seconde (LOG_SHIPPEMENT.T_FILE_STORAGE_FST) liste les fichiers du stockage et n’est à utiliser que si l’arborescence du stockage est différente entre le serveur source et le serveur cible :

  • SDB_ID : clef étrangère référençant la précédente table (LOG_SHIPPEMENT.T_SOURCE_DATABASE_SDB)
  • FST_LOGICAL_FILE_NAME : nom logique du fichier de stockage
  • FST_PHYSICAL_PATH : chemin de stockage sur le serveur cible pour le fichier logique considéré

Exemple d’utilisation :

Ce qui fait que seule la base « MA BASE TEST » sera « log shippé » et mes fichiers logiques placés dans les bons répertoires de destination.

Et nos procédures…

La procédure LOG_SHIPPEMENT.P_DO_RESTORE effectue automatiquement toutes les tâches continues du « log shippement » :

  • si la base n’existe pas, recherche la dernière sauvegarde complète, la restaure et applique la restauration de toutes les sauvegardes des journaux de transactions complémentaires.
  • si la base existe déjà en mode de restauration, la complète avec toutes les sauvegardes transactionnelles complémentaires

Elle doit être planifiée à la même fréquence que les sauvegardes transactionnelles (par exemple toutes les 10 minutes)

Les procédures suivantes, ont les fonctions indiquées :

  • LOG_SHIPPEMENT.P_FORCE_STANDBY : place la base passée en argument, en mode « veille » avec lecture seule (STANDBY) lorsqu’elle est en état de restauration. À n’utiliser que temporairement pour lire les données.
  • LOG_SHIPPEMENT.P_FORCE_LOGSHIP : replace la base passée en argument, en mode « restauration » pour appliquer à nouveau le processus de « log shippement », si la base est dans l’état « veille » avec lecture seule (STANDBY).
  • LOG_SHIPPEMENT.P_FORCE_RECOVERY : place la base passée en argument, en mode de production lorsqu’elle est en état de restauration.

La dernière procédure est celle à utiliser pour remettre la ou les base(s) en état de produire afin d’assurer la reprise d’activité.

Lien de téléchargement du Log Shipping automatisé


Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
* Le site sur les SGBD relationnels et le SQL : https://sqlpro.developpez.com *
* le blog SQL, SQL Server, SGBDR... sur : https://blog.developpez.com/sqlpro/ *
* Expert Microsoft SQL Server, MVP (Most valuable Professional) depuis 14 ans *
* Entreprise SQL SPOT : modélisation, conseil, audit, optimisation, formation *
* * * * * Enseignant CNAM PACA - ISEN Toulon  -  CESI Aix en Provence * * * * *

 

 

Ce contenu a été publié dans Procédure de maintenance, Procédures MS SQL Server, scripts SQL, SQL Server, Uncategorized. Vous pouvez le mettre en favoris avec ce permalien.