Base de données en miroir

fournit le failover au niveau de la base de
données. Si la base de données primaire (ou principale) est
défaillante, une seconde base de données peut prendre le relais
en 2 ou 3 secondes. Le risque de perte de données est
par conséquent nul. Le serveur en miroir sera toujours synchronisé
avec la transaction courante en cours de traitement
sur le serveur de base de données primaire.
Le mode miroir de la base de données peut être établi de
telle sorte que le basculement se produise automatiquement ou manuellement. Le mode manuel est intéressant pour les
tests mais, en production, il vaut mieux que le basculement
de la base de données soit automatique. Le mode miroir
fonctionne avec tout matériel standard. Aucun système spécial
n’est nécessaire, et le serveur primaire et le serveur en
miroir ne sont pas forcément identiques. De plus, le débit
des transactions est très peu influencé par le mode miroir de
la base de données. Et, contrairement à  des solutions de
clustering haute disponibilité, aucun stockage partagé n’est
nécessaire entre les serveurs primaire et en miroir.
Comme le montre la figure 1, la base de données en miroir
implique trois systèmes principaux : le serveur primaire,
le serveur en miroir et le témoin. Le serveur primaire est le
système qui fournit les services base de données. Selon la
configuration du serveur en miroir, les serveurs primaire et
en miroir peuvent s’échanger leurs rôles. Le témoin constitue
un tiers indépendant qui aide à  déterminer quel système
assumera le rôle de serveur primaire. Chaque système obtient
un vote stipulant quel serveur sera le serveur primaire :
deux votes identiques nomment le gagnant. Ce point est important
parce que les communications entre les serveurs primaire
et en miroir pourraient être interrompues, auquel cas
chaque serveur s’autoproclamerait serveur primaire. Le témoin
les départagerait alors par son vote.
La base de données en miroir fonctionne en envoyant
des journaux de transactions entre les serveurs primaire et
en miroir. On pourrait dire que la base de données en miroir
est une application d’envoi de journaux de transactions en
temps réel. Une ou plusieurs bases de données peuvent être
mises en miroir.
Quand un système client envoie une
requête au serveur primaire, celui-ci écrit
la requête dans son journal de transactions
avant de l’écrire dans le fichier de
données, parce que Yukon utilise un journal
à  écriture anticipée. Ensuite, le serveur
primaire envoie l’enregistrement de transaction
au serveur en miroir. Celui-ci écrit
l’enregistrement dans son journal de transactions
puis envoie un accusé de réception
au serveur primaire. Ainsi, les deux
serveurs contiennent les mêmes données
dans leurs journaux respectifs. Dans le cas d’opérations
COMMIT, le serveur primaire attend l’accusé de réception
avant d’envoyer au client une réponse signifiant la fin de
l’opération.
Pour initialiser la base de données en miroir, vous devez
sauvegarder la base de données à  mettre en miroir sur le serveur
primaire puis restaurer cette sauvegarde sur le serveur
en miroir. Cette opération met en place les données et le
schéma sous-jacents de la base de données. Un état de reprise
continu (c’est-à -dire, prendre les données du journal et
mettre à  jour le fichier de données) garde les fichiers de
données à  jour sur le serveur en miroir.