Le Log Shipping SQL Server
Le Log Shipping est un excellent moyen de mise en place d’un PRA.
Le Log Shipping ne permet pas d’avoir le principal et le secondaire dans un état parfaitement synchronisé.
Pour cela, il y a le Mirroring (déprécié), la réplication et surtout les groupes de disponibilité Always On (HADR).
Le Log Shipping est très souvent utilisé dans le cadre de migrations avec coupure de service minimum.
L’agent SQL Server permet la planification de JOB avec une fréquence minimum de 10 secondes, ce qui dans le cas d’une migration permet une bascule avec une coupure de service extrêmement réduite.
Il reste bien sûr la modification des chaines de connexions applicatives, etc.
Le Log Shipping permet par exemple, d’avoir un serveur principal dans une version antérieure au serveur secondaire, cas typique d’une migration, ce qui n’est pas le cas du Mirroring et de l’Always On (sauf en cas de migration ou il est possible d’ajouter un réplica de version ultérieure en mode asynchrone).
Si le serveur principal et le serveur secondaire sont de la même version (Major version), il est possible de rendre les bases de données du serveur secondaire accessibles en lecture seule.
Cela permet par exemple, d’y connecter l’alimentation d’un Datawarehouse pour faire du Reporting ou tout autre process qui ne nécessite qu’un accès en lecture et ainsi soulager le serveur principal.
Il faut toutefois vérifier l’aspect License surtout avec SQL Server Standard édition.
Le Log Shipping permet d’avoir plusieurs serveurs secondaires.
Log Shipping simple avec un principal et un secondaire.
Basculement de rôle des serveurs en Log Shipping simple (2 serveurs)
Il y a deux manières de procéder au basculement de rôle dans le cadre d’un Log Shipping Simple.
Vous pouvez mettre la base de données de secours en ligne en faisant un simple RESTORE WITH RECOVERY, puis en faire une sauvegarde complète et la restaurer sur la base de données principale (précédemment) pour l’initialiser pour l’envoi de journaux.
Cependant, cette approche peut être lourde, surtout si la base de données est volumineuse.
Les étapes suivantes vous permettront d’inverser les rôles des serveurs sans avoir à initialiser la nouvelle base de données de secours (ex principale).
1-Désactivez le travail de Backup du Log Shipping sur le serveur principal.
2-Sur le serveur de secours, exécutez les jobs de copie et de restauration d’envoi de journaux pour restaurer toutes les sauvegardes restantes du journal des transactions.
3-Désactivez les travaux de copie et de restauration des journaux sur le serveur secondaire.
4-Sur le serveur principal, faites une dernière sauvegarde du journal des transactions à l’aide de l’option NORECOVERY.
5-Sur le serveur secondaire, restaurez cette sauvegarde du journal des transactions à l’aide de l’option RECOVERY.
6-Sur le serveur secondaire (qui sera désormais le serveur principal), faites un clic droit sur la base de données et sélectionnez Propriétés -> Envoi des journaux de transactions.
7-Activez la base de données pour qu’elle devienne la base de données principale et configurez les paramètres du serveur de sauvegarde et du serveur secondaire.