Le principe du « Log Shipping » ou envoi des journaux de transactions, consiste à maintenir une base de données esclave en état de restauration permanente pour qu’en cas de cas de sinistre on puisse basculer la production sur le serveur de secours qui prends alors le relais de la base maître. Le basculement ne pouvant se faire que manuellement même s’il est possible d’automatiser ceci au moyen d’un développement particulier.

### CECI CONCERNE TOUT LES SERVEURS SQL APTE AU LOG SHIPPING ###

Configuration technique :

Initiale :
on effectue une sauvegarde complète de la base de données maître que l’on restaure en mode d’attente sur le serveur esclave (par exemple dans MS SQL Server RESTORE LOG … WITH NORECOVERY de la commande BACKUP).
La base esclave est inaccessible. Elle se présente comme étant en état de restauration.

Production :
A intervalle régulier (par exemple 1 heure) on sauvegarde le journal de transaction et le fichier ainsi généré est envoyé au serveur esclave.
Sur le serveur esclave on restaure les différents journaux de transaction dans l’ordre d’arrivée (afin de conserver le séquencement des LSN : Log Segment Number) , mais en conservant toujours en stand by le dernier fichier de sauvegarde du journal de transaction et ceci avec une restauration en mode d’attente (par exemple dans MS SQL Server RESTORE LOG … WITH NORECOVERY).

En effet, comme par nature on ne sait pas quand le système tombera en panne et qu’il faut passer le dernier fichier reçut non pas en mode d’attente (par exemple dans MS SQL Server RESTORE LOG … WITH NORECOVERY), mais en mode de production (WITH RECOVERY), on ne passe jamais le dernier fichier du journal de transaction tant que l’on a pas reçu le suivant.

Basculement :
On restaure le dernier fichier de sauvegarde du journal de transaction en mode de production (par exemple dans MS SQL Server RESTORE LOG … WITH RECOVERY) sur le serveur cible qui devient alors productif (les utilisateurs peuvent travailler dessus).

NOTA : s’agissant de deux serveurs différents il faut prévoir que toutes les applications utilisant cette base soient redoutées vers le nouveau serveur. Par exemple, modification du nom du serveur dans le DSN ODBC.
On notera aussi que la distance peut être très longue entre les seveurs (WAN) par exemple un serveur maître à Paris, l’autre à New York.
Enfin, un répertoire partagé hébergeant les fichiers de sauvegarde et visible par les deux serveurs SQL doit être mis en place pour ce faire.

Perte de données :
La perte de données dans le cas de cette solution de haute disponibilité est au maximum du laps de temps de latence entre deux envois de journaux. En moyenne elle est de la moitié de ce même laps de temps.
En pratique on peut descendre jusqu’à 10 à 15 minutes. Il devient déraisonnable d’espérer faire cela a la minute, sauf pour un serveur peu sollicité ne lançant que des petites transactions et dont on s’assure des écritures physique le plus rapidement possible (par exemple dans MS SQL Server CHECKPOINT).

Problèmatique :
En cas de longue transaction (d’une durée supérieure au temps de latence), la sauvegarde du journal pourra ne rien contenir, les transactions étant bloquées jusqu’à finalisation de la transaction longue. Le journal va par conséquent grossir jusqu’à la finalisation de la transaction.
En cas de sauvegarde « sauvage » il faut réinitialiser le processus, sauf si cette sauvegarde a été faite avec une option qui préserve le séquencement du « log shipping » (par exemple dans MS SQL Server avec BACKUP LOG … WITH COPY ONLY )

Avantages et inconvénients :
N’importe quelle SGBDR permettant les sauvegarde de journaux de transactions et apte à faire du « log shipping ».
La distance entre les machine maître et esclave peut être très importante (des milliers de km en pratique).
C’est une solution qui permet de migrer une base d’une machine à l’autre avec un minimum de temps d’interruption.
La solution est simple à mettre en Å“uvre, mais demande une grande rigueur au niveau de l’administration : le séquencement des journaux doit être sans faille et aucune sauvegarde sauvage ne doit être entreprise sur la production.
On peut alimenter plusieurs serveurs esclave.
Du fait du temps de latence relativement long (en générale quelques dizaines de minutes), la perte de données peut être important et par conséquent inacceptable dans certains cas.
La solution fonctionne base par base. Pour un grand nombre de bases cela devient pénalisant à inexploitable.

Autres solutions :
La clusterisation (mise en cluster de différents serveurs)
Le mirroring de bases de données.

SGBDR supportant le log shipping :
MS SQL Server, IBM DB2, Oracle, PostGreSQL…

SGBDR ne supportant pas le log shipping :
MySQL

### CECI CONCERNE EXCLUSIVEMENT MS SQL SERVER ###

En pratique :
L’ensemble du log shipping peut être mis en place via l’interface graphique dans SQL Server 2008, ou par script (depuis la version 7…) et se trouve piloté par différentes procédures stockées. Néanmoins il est assez facile de développer sa propre façon de faire en utilisant notamment l’Agent SQL qui est l’outil de planification dédié et synchronisé à SQL Server.
Remarque : la solution de log shipping peut être mise en œuvre sur la version gratuite de SQL Server (Express).

-------- 

Frédéric Brouard, SQLpro - ARCHITECTE DE DONNÉES, http://sqlpro.developpez.com/ 

Expert bases de données relationnelles et langage SQL. MVP Microsoft SQL Server 

www.sqlspot.com : modélisation, conseil, audit, optimisation, tuning, formation 

* * * * *  Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence  * * * * *