LOG SHIPPING Avec SQL Serveur 2005
Date de publication : 31 juillet 2008
Par
Yann L'Arvor
Le log shipping est un moyen de tirer parti des opérations de transaction log backup/restore de SQL Server afin de dupliquer (to ship : littéralement : amener par bateau... (vive les perfs ^^) ) l'information d'une base de donnée primaire vers une ou plusieurs DB secondaires.
Depuis SQL Server 2005 ce processus peut être automatisé plus facilement que sur les précédentes versions. Le backup du log, la distribution de celui ci vers la (les) différente(s) machine(s) de destination ainsi que la restauration de ce backup sur la (les) DB cible(s), qui sont les 3 étapes du processus que nous sommes en train de décrire, peuvent être misent en place grâce à une GUI à portée de clic droit dans SQL Server Management Studio et nous économise donc du temps qui autrefois (on se sent déjà vieux...) était dépensé en scripting. Une fois le log shipping mis en place, vous pourrez retrouver toutes ces opérations implémentées sous forme de job sql dans l'agent SQL serveur.
I. Analyse préliminaire
II. Matériel
III. Introduction
IV. Mise en place d'un log shipping à travers l'assistant.
IV-A. Travail préparatoire
IV-B. Appel de l'assistant
IV-B-1. Première étape : Définition du serveur primaire
IV-B-2. Deuxième étape : Définition du / des serveurs secondaires
IV-B-3. Troisième étape : Définition ou non d'une instance moniteur
IV-C. Résultat du log shipping sur le serveur secondaire.
V. Basculement de l'instance principale sur l'instance secondaire
VI. Conclusion
VII. Remerciements
I. Analyse préliminaire
Certains éléments sont à prendre en considération avant d'opter pour cette solution :
- Le log shipping concerne une base de données spécifique. Si l'on veut étendre le processus à d'autres bases de données, il faudra configurer autant de fois le processus. Le plus petit objet réplicable est donc une base de données. (sur une échelle : instance – db – schéma - table - enregistrement)
- Les log backups sont copiés et restaurés sur chaque serveur secondaire. Nous avons donc une redondance des fichiers de backups, ce qui consomme de l'espace disque.
- Le temps de décalage entre les données sources et target dépend principalement de la fréquence des opérations. Au moins 2 questions : « Quel décalage au niveau des données entre le serveur source et le serveur secondaire sont acceptables ? » , « Quelle quantité de données mesurée en minutes pouvons nous accepter de perdre en cas de crash ? »
- Le réseau est un élément important, il assure la disponibilité des fichiers de backups.
- En cas de crash de la base de donnée principale, il n'y a pas de basculement automatique vers une base de données secondaire.
- Tous les log backups d'une même DB doivent être restaurés séquentiellement. Si vous prenez un log backup à un autre moment (maintenance plan, job...) il faudra vous assurer que ce log soit lui aussi correctement restauré sur toutes les DB de destination entre les 2 logs backups agendés pour le log shipping entre lesquels il a été pris.
II. Matériel
Nous travaillerons sur un poste client Windows XP Pro avec deux instance SQL serveur 2005 Developper nommées PLUTON ( Instance Principale ) et PLUTON\LOGSHIPPING ( Instance nommée secondaire ).
III. Introduction
Le but est de montrer par l'exemple la mise en place d'un logshipping entre 2 serveurs distant ou non à l'aide de l'assistant et surtout la technique pour basculer entre le serveur principal et le serveur secondaire le jour où c'est nécessaire.
Nous vous renvoyons au livre PRO SQL SERVEUR 2005 HIGH AVAILABILITY de Allan Hirt chez l'éditeur APRESS pour une étude complète de tous les détails d'un log shipping.
IV. Mise en place d'un log shipping à travers l'assistant.
IV-A. Travail préparatoire
Un log shipping consiste à sauvegarder le log de l'instance principale, de déplacer le fichier de sauvegarde sur l'instance secondaire, et de restaurer le log sur l'instance secondaire. Pour communiquer entre les deux instances, on utilise un répertoire partagé entre les deux serveurs. Dans notre cas, un répertoire local.
Dans notre cas, il suffit de créer un répertoire sur le disque nommé C:\Logshipping et de le mettre en partage réseau sur le même nom. Veuillez quand même faire attention à ce que le compte de service de l'agent sql serveur des 2 instances ait des droits d'écriture et de lecture sur ce répertoire.
IV-B. Appel de l'assistant
Je sélectionne ma base, la base CTIFL, qui doit être en mode recovery full et non simple bien évidemment, le mode recovery full indique que l'on travaille avec le journal de transaction, en mode simple, il est vidé automatiquement chaque seconde. Nous avons besoin d'un journal pour faire du logshipping.
Je fais un clic droit. Je clique sur taches puis envoyer les journaux de transactions.
La page de propriété s'affiche.
IV-B-1. Première étape : Définition du serveur primaire
Je clique sur Activer en tant que base de données primaire…
Je clique sur Paramètres de sauvegarde.
Je vais définir le lieu où l'on dépose le journal après la sauvegarde, le délai entre chaque opération de sauvegarde.
J'indique le chemin réseau de mon répertoire dans la première zone de saisie \\PLUTON\logshipping
J'indique le chemin local de mon répertoire dans la deuxième zone de saisie c:\logshipping
Sans ces deux chemins, vous ne pouvez pas continuer.
Par défaut, j'accepte la mise en place des travaux, un backup toutes les 15 minutes.
Le bouton OK est accessible, je valide.
IV-B-2. Deuxième étape : Définition du / des serveurs secondaires
Je reviens à l'écran précédent mais cette fois la zone Bases de données secondaires est accessible.
Je clique sur AJOUTER pour indiquer mon serveur secondaire PLUTON\LOGSHIPPING.
Un nouvel écran apparaît :
Je clique sur Se connecter : je me connecte à mon serveur secondaire
Après connexion, l'écran devient
J'accepte les informations de l'écran " initialiser la base de données secondaire " qui indique qu'une restauration à partir de ma base actuelle va être effectuée. On part sur de bonnes bases, avant de poster les journaux de transactions d'une base à l'autre, on met en correspondance les deux bases. C'est le rôle de ce premier écran initialiser la base secondaire.
L'écran qui nous intéresse, pour continuer, est l'écran " Copier les fichiers ", nous devons indiquer le chemin local du répertoire logshipping, comme nous sommes en local, il s'agit d'indiquer c:\logshipping.
Le serveur de destination copie les données du répertoire partagé vers le répertoire de restauration, où le script de restauration viendra chercher les données. C'est le rôle de cette étape copier les fichiers.
Nous acceptons par défaut le délai de 15 minutes entre chaque copie.
Nous avons une troisième étape Restaurer le journal de transaction dans laquelle nous précisons le délai, on laisse 15 minutes entre chaque restauration.
Nous cliquons sur OK pour revenir à l'écran propriété.
IV-B-3. Troisième étape : Définition ou non d'une instance moniteur
Nous ne choisissons pas d'indiquer une instance de serveur moniteur, nous avons donc terminé notre mise en place de logshipping
On peut cliquer sur OK pour lancer la génération des travaux sur les deux serveurs, la sauvegarde-restauration initiale pour mise en adéquation de la base secondaire.
Nous avons terminé de mettre en place le log shipping entre le serveur PLUTON et le serveur PLUTON\LOGSHIPPING.
Toutes les quinze minutes, les informations du serveur PLUTON, de la base CTIFL, sont copié sur le serveur PLUTON\LOGSHIPPING sur la base CTIFL.
IV-C. Résultat du log shipping sur le serveur secondaire.
Tout cela est très intéressant mais une surprise nous attend quand on se rend sur le serveur PLUTON\LOGSHIPPING
En effet, la base CTIFL est en mode restauration. Elle n'est pas utilisable pour le moment. Elle écoute… dirons nous…
V. Basculement de l'instance principale sur l'instance secondaire
Nous pouvons laisser fonctionner notre logshipping des semaines ainsi, le serveur principal - base ctifl est dupliqué sur le serveur secondaire - base ctifl avec quinze minutes de retard.
Maintenant. Imaginons que nous souhaitions basculer du serveur principal sur le serveur secondaire. Le but d'avoir un serveur secondaire est de pouvoir s'en servir si le serveur principal vient à tomber en panne.
D'après la compréhension que j'ai du log shipping et notamment, le fait que la base secondaire soit passive, signifie que l'on doit garder la main sur le serveur principal un minimum pour permettre au moins la sauvegarde du journal de queue. Sans cela, tout est perdu il me semble ! Cela me parait la principale limitation de cette technique.
D'abord, il va falloir prévoir de dupliquer les logins du serveur principal sur le serveur secondaire. C'est une opération à prévoir longtemps à l'avance.
Ensuite, dans notre fichier de configuration, dans la chaîne de connexion, nous aurons pris la précaution d'ajouter à la chaîne de connexion un FailoverPartner qui sera activé dès que le serveur principal ne répondra plus.
Ensuite, il est nécessaire d'effectuer une sauvegarde du journal de queue de log sur le serveur principal.
Avec SQLCMD, vous effectuez un BACKUP LOG CTIFL TO DISK = 'C:\LOGSHIPPING\CTIFL_FINAL.TRN'.
Vous revenez sur le manager et vous effectuez une restauration WITH RECOVERY sur la base CTIFL secondaire avec la commande RESTORE LOG CTIFL FROM DISK = 'C:\LOGSHIPPING\CTIFL_FINAL.TRN' WITH RECOVERY.
La commande WITH RECOVERY arrête l'écoute et rend accessible la base CTIFL du serveur secondaire.
Votre restauration du fichier journal de queue vous permet d'avoir une base au même stade que la base CTIFL sur le serveur primaire.
VI. Conclusion
La présentation est rapide mais elle donne à comprendre le principe de mise en place d'un log shipping sur SQL Serveur 2005. Elle explique également comment sortir du mode NORECOVERY de la base secondaire.
VII. Remerciements
Remerciements particuliers à Ptit Dej pour ses compléments sur les concepts.
Copyright © 2008 Yann L'Arvor.
Aucune reproduction, même partielle, ne peut être faite de ce site ni de l'ensemble de
son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur.
Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 €
de dommages et intérêts. Droits de diffusion permanents accordés à Developpez LLC.
