[SQL Server] Un peu de théorie sur le database mirroring…

Ce petit billet présente le database mirroring et son fonctionnement.

Qu’est-ce que le database mirroring ?

Le database mirroring est une technique qui permet de synchroniser deux bases de données situées sur deux serveurs distincts, tout en disposant de la faculté de basculer automatiquement d’un serveur à l’autre.

Du point de vue fonctionnel, les serveurs communiquent entre eux en utilisant des endpoints (points de connexion ou de terminaison). Et ils se connectent sur des endpoints via des informations d’authentification, qu’il s’agisse d’un login Windows (dans un domaine uniquement) ou d’un login SQL.

Grosso-modo, le database mirroring fonctionne basiquement comme suit :

  1. Soient A et B, deux bases de données respectivement situées sur une instance IA et IB.
  2. A, qui joue le rôle de base principale, envoie à B (base secondaire) ses journaux de transactions un par un.
  3. IB restaure en permanence les journaux de transactions reçus par B.
  4. En cas de crash, un witness (serveur témoin, quand il existe, et dont le rôle principal est de servir d’arbitre entre les bases A et B) effectue une bascule automatique de façon à ce que B devienne la base principale et A, la secondaire.

Le schéma ci-dessous résume le fonctionnement global d’une session de mirroring :


Légende :
IA : instance A contenant la base principale à synchroniser.
IB : instance B contenant la base secondaire appelée « miroir ».
IW : instance témoin appelée witness.

Les modes de fonctionnement du database mirroring

Il existe deux modes de database
mirroring :

  • Asynchrone : dispositif offrant une haute-performance de la base de données dans la mesure où les transactions ne sont réalisées que sur le serveur principal et ne sont répercutées sur le serveur secondaire (le miroir, en l’occurrence) que lors qu’un COMMIT a été effectué. Son principal avantage est donc de limiter tout ralentissement du serveur principal.
Le mode haute-performance peut être utile dans un scénario de récupération post-crash dans lequel les serveurs principal et secondaire (miroir) sont très éloignés et où l’on ne souhaite pas que de petites erreurs affectent le serveur principal.
  • Synchrone : dispositif offrant une haute-sécurité de la base de données dans la mesure où les transactions sont effectuées sur le serveur principal puis rapidement 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 configuré de telle manière qu’en cas de crash du principal la base secondaire est automatiquement activée, le temps que le serveur principal soit réparé. Le basculement automatique est assuré par un troisième serveur appelé témoin.
Le mode haute-sécurité peut être utile dans un scénario de récupération post-crash dans lequel il y a basculement automatique sans perte de données.

L’utilisation d’un 3ème serveur appelé witness (ou témoin) n’est pas une nécessité (et il est même conseillé de le rendre inactif en cas d’utilisation en mode asynchrone, pour des raisons de fonctionnement[1]) pour le déroulement d’une session miroir. Néanmoins, si le basculement automatique (dans ce cas, on parle du mode synchrone avec basculement automatique)
est souhaité en cas d’indisponibilité de la base de données principale, son utilisation devient obligatoire.

Pour la mise-en-place d’une session miroir, la solution la plus sécurisée (et qui fonctionne avec ou sans domaine) consiste à créer des logins SQL avec authentification par certificat. Ces certificats sont auto générés par MSSQL lui-même, moyennant la création d’une master key (clé maîtresse) sur chaque serveur (y compris le witness,
quand il existe) qui servira à protéger les certificats et leurs clés.

Pour aller plus loin…

Dans un prochain billet, nous verrons comment mettre en place le database mirroring sous SQL Server Management Studio et en T-SQL « pur ».


[1]Notamment pour la simple raison qu’en cas d’activation de l’utilisation d’un witness en mode asynchrone, et en cas d’indisponibilité du serveur principal, il est nécessaire de forcer la connexion du serveur miroir vers le witness afin que la base secondaire puisse continuer à fonctionner.
Publicités

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s