A mi-chemin entre la réplication et la mise en cluster de serveurs, la mise en miroir de bases de données est une bonne solution de haute disponibilité. Le principe est simple : les transactions effectuées sur l’instance principale sont également envoyées à l’instance miroir. De cette manière en cas de crash du principal il est possible de basculer (automatiquement ou non) sur le serveur miroir avec une perte de données au mieux inexistante et au pire minimale.
A la différence de la réplication ou d’un cluster, la base miroir n’est pas accessible en même temps que la base principale et ne sera en fait utilisée qu’en cas de problème sur le principal. Ce n’est donc pas un moyen de répartir la charge sur plusieurs serveurs mais bien un hot backup, c’est-à-dire une sauvegarde à jour de la base disponible immédiatement.
Dans la suite de l’article je vais détailler les étapes de mise en miroir d’une base de données avec SQLServer 2005.
Pré-requis et principes de base
En premier lieu il faut s’assurer que la version de SQLServer utilisée permet de faire des mises en miroir. Les versions Entreprise et Développeur permettent toutes les opérations liées aux miroirs alors que la version Standard ne permet pas le mode Hautes Performances. Les versions Express et Groupe de Travail ne permettent que de prendre le rôle de Témoin.
| Entreprise | Développeur | Standard | Groupe de Travail | Express | |
|---|---|---|---|---|---|
| Témoin | X | X | X | X | X |
| Partenaire | X | X | X | ||
| Haute Sécurité | X | X | X | ||
| Hautes Performances | X | X |
Voyons à présent un peu plus en détail la signification de ces termes :
– Partenaire : il s’agit tout simplement d’une instance impliquée dans une mise en miroir. A noter d’ailleurs qu’une mise en miroir peut se faire sur un seul et même serveur disposant de deux instances SQLServer.
– Témoin : il s’agit d’une instance optionnelle qui vérifiera la disponibilité des deux partenaires du miroir. Si le principal ne répond pas, le témoin interprètera cela comme un crash du serveur et, selon la configuration, activera automatiquement la base miroir. Ce comportement est équivalent au quorum pour les clusters. Cela soulève un point important : si l’utilisation du principal est très importante il est possible que le témoin n’arrive pas à le contacter dans le délai imparti (10 secondes par défaut). Cela peut alors poser un problème de basculement automatique intempestif sur le miroir. Il est recommandé de garder l’utilisation CPU inférieure à 50%.
– Haute sécurité (High Safety) : dans ce mode de mise en miroir, les transactions sont effectuées sur le principal et envoyées au miroir. Une fois que le miroir indique que la transaction a été effectuée, le principal effectue son COMMIT. Ce mode est donc synchrone et peut-être configuré de telle manière qu’en cas de crash du principal la base miroir soit automatiquement activée.
– Haute performances (High Performance) : dans ce mode, les transactions sont effectuées sur le principal et une fois le COMMIT effectué sont transmises au miroir. Ce mode est donc asynchrone et permet de ne pas ralentir le principal. Il n’y a pas besoin de témoin dans ce mode.
Avant le Service Pack 2 de SQLServer 2005, la mise en miroir était encore en status expérimental et ne pouvait être activée directement à moins de lancer l’instance avec un switch 1400 (net start mssqlserver /T1400).
Il est recommandé d’installer le SP2 pour pouvoir utiliser la mise en miroir.
Mise en miroir d’une base en mode Hautes Performances
Dans un premier temps il est conseillé de faire quelques tests dans le mode qui a le moins de chances d’impacter l’instance principale, c’est-à-dire le mode Hautes Performances. En effet, les modes Haute Sécurité peuvent d’une part ralentir le principal lors de l’attente de la confirmation du miroir et d’autre part causer une bascule automatique accidentelle en cas de problème sur le principal.
– réaliser un backup complet de la base à mettre en miroir et le restaurer sur l’instance miroir avec l’option WITH NORECOVERY (deuxième bulle de l’onglet Options dans l’interface de restauration). Si vous obtenez une erreur 1418 c’est sans doute du à l’oubli de l’option WITH NORECOVERY.
La base est alors visible en état Restoring…
– réaliser un backup du journal de transactions de la base à mettre en miroir et le restaurer sur l’instance miroir avec l’option WITH NORECOVERY (deuxième bulle de l’onglet Options dans l’interface de restauration). Si vous obtenez une erreur 1416 c’est sans doute du à l’oubli de l’option WITH NORECOVERY.
La base est toujours en état Restoring…
– sur le principal, faire un clic droit sur la base à mettre en miroir puis sélectionner Task > Mirror. L’assistant de mise en miroir se lance et il suffit ensuite de cliquer sur le bouton Configure Security. Cliquer ensuite sur Next, puis sur No et Next. Sélectionner l’instance principale, cliquer sur Next, sélectionner l’instance miroir et s’y connecter puis cliquer sur Next. Renseigner au besoin les comptes nécessaires puis cliquer sur Next et Finish.
Une fois la configuration terminée on peut lancer la mise en miroir elle-même et la première synchronisation, qui doit normalement être très rapide. Une fois cette synchronisation effectuée la base se retrouve en état Mirror, Synchronized / Restoring…).
Etat des bases miroir
Il est possible de suivre l’état du miroir en faisant un clic droit sur une des bases du principal et de faire Tasks > Launch Database Mirroring Monitor.
Mise en miroir d’une base en mode Haute Sécurité
La mise en place d’un miroir Haute Sécurité est globalement identique au mode Hautes Performances excepté le fait qu’une troisième instance sera désignée comme témoin pour vérifier la disponibilité des deux instances partenaires.
Dans l’assistant de mise en miroir il faut donc répondre Yes à la première question. Une étape supplémentaire apparaîtra alors après la désignation des deux instances partenaires demandant d’indiquer l’instance témoin (Witness).
Il faudra de plus déterminer si l’on souhaite une bascule automatique vers le miroir en cas de crash du principal ou non, cela dépendra bien évidemment des besoins de l’entreprise ainsi que des tests qui auront été faits.
