Convertir une configuration Log Shipping vers le Database Mirroring

Posted by Yukon on 2. August 2011 16:09

Il peut être parfois intéressant, voire avantageux de convertir une installation log shipping vers du database mirroring, car ce dernier fournit les avantages suivants par rapport au log shipping :

• Pas de perte de données (mode synchrone)
• Basculement automatique possible (mode synchrone avec témoin)

Par contre, il ne faut pas perdre de vue certaines contraintes imposées par le database mirroring :

• Le Database Mirroring nécessite une base de donnée en mode de récupération FULL, alors que le log shipping fonctionne avec des bases en mode BULK_LOGGED ou FULL

Log Shipping a peu ou pas d’impact sur la performance des applications sur le serveur principal. En effet, le database mirroring peu éventuellement impacter la performance des applications si ce dernier gère un volume important de « log » générée.

Ainsi, il est possible de convertir une installation log shipping vers du database mirroring sans effectuer une sauvegarde complète suivie d’une restauration sur la base mirroir.
La procédure ci-dessous décrit les grandes étapes de mise œuvre de la conversion d’une configuration log shipping vers le database mirroring ; Cette approche peut être utilisée dans le cas où vous disposez d’une configuration Log Shipping entre deux serveurs SRV1 (primaire) et SRV2 (secondaire). Votre objectif étant de minimiser la durée d’indisponibilité de la plateforme pendant une phase de maintenance planifiée sur le serveur primaire ; Une première solution est de basculer la base de donnée du serveur SRV1 vers le secondaire, mais l’application ne basculera pas automatiquement et la durée d’indisponibilité peut s’étaler sur plusieurs minutes. Une approche alternative serait :

1. De convertir la configuration log shipping en database mirroring (mode synchrone) en suivant les étapes décrites dans la section « mise en œuvre ».
2. Effectuer un basculement manuel de la base de données du principal vers le miroir. Ainsi l’ancien miroir devient le serveur principal et l’application peut se reconnecter automatiquement au nouveau principal et continuer à fonctionner.
3. Une fois l’opération de maintenance terminée, vous pouvez rebasculer vers le serveur principal original.
4. Supprimez ensuite la configuration du database mirroring
5. Réinitialisez le log shipping.

Mise en œuvre

1. S’assurer du bon fonctionnement du log shipping entre les serveurs SRV1 et SRV2 (SRV1 en principal et SRV2 en secondaire) : vérifiez l’état des jobs backup, copy et restore dans l’historique des jobs SQL Agent. Vérifiez aussi que la base secondaire est dans l’état NORECOVERY, et non en STANDBY.
2. Configurez les différentes étapes du database mirroring : securité, endpoints, privilèges, etc…
3. Sur SRV1, désactivez le job de backup log. Attendez que tous les backups de log soient copiés et restaurés sur le serveur secondaire. (Vous pouvez également exécuter manuellement le job de copie et ensuite le job de restauration sur le serveur secondaire ; ce qui permettra de gagner près de 15 minutes).
4. Une fois la copie et la restauration effectuées sur le serveur secondaire, désactivez les jobs correspondants sur ce dernier.
5. Activez maintenant le database mirroring entre les deux serveurs, avec SRV2 comme miroir et SRV1 comme le principal. Modifiez manuellement l’option safety level si vous souhaitez passer en mode asynchrone (car synchrone par défaut).
6. Supprimez la configuration log shipping entre SRV1 et SRV2
7. Enjoy !