Mise en miroir synchrone de bases de données (mode Haute sécurité)

Lorsque la sécurité des transactions est définie à FULL, la session de mise en miroir de la base de données s'exécute en mode haute sécurité et fonctionne de manière synchrone après une phase initiale de synchronisation. Cette rubrique décrit en détail les sessions de mise en miroir de bases de données qui sont configurées pour fonctionner de manière synchrone. Nous supposons que vous connaissez les concepts de base de la mise en miroir de bases de données. Pour plus d'informations, consultez Sessions de mise en miroir de bases de données.

Pour passer en mode synchrone pour une session, le serveur miroir doit synchroniser la base de données miroir avec la base de données principale. Lorsque la session commence, le serveur principal commence à envoyer son journal actif au serveur miroir. Le serveur miroir écrit aussi vite que possible tous les enregistrements de journal entrants sur le disque. Une fois cette opération effectuée, les bases de données sont synchronisées. Tant que les partenaires restent en communication, les bases de données sont synchronisées.

Remarque :
Pour surveiller les modifications d'état dans une session de mise en miroir de base de données, utilisez la classe d'événements Database Mirroring State Change. Pour plus d'informations, consultez Classe d'événements Database Mirroring State Change.

Après que la synchronisation a pris fin, chaque transaction validée dans la base de données principale l'est également sur le serveur miroir, ce qui garantit la protection des données. En effet, la transaction n'est validée dans la base de données principale qu'une fois que le serveur principal a reçu un message du serveur miroir lui indiquant que le journal des transactions est bien renforcé sur le disque. Notez que le fait d'attendre ce message augmente la latence de la transaction.

Le temps nécessaire à la synchronisation dépend essentiellement du décalage de la base de données miroir par rapport à la base de données principale au début de la session (ce qui se mesure par le nombre de d'enregistrements du journal initialement reçus du serveur principal), de la charge de travail sur la base de données principale et de la vitesse du système de mise en miroir. Après la synchronisation d'une session, le journal renforcé qui doit être réutilisé sur la base de données miroir reste dans la file d'attente de restauration par progression. Pour plus d'informations, consultez Sessions de mise en miroir de bases de données.

Dès que la base de données miroir est synchronisée, l'état des deux copies de la base de données devient SYNCHRONIZED.

L'opération se déroule de la manière suivante :

1. Lors de la réception d'une transaction d'un client, le serveur principal l'écrit dans le journal des transactions.
2. Le serveur principal écrit la transaction dans la base de données, et simultanément, il envoie l'enregistrement du journal au serveur miroir. Le serveur principal attend un accusé de réception du serveur miroir avant de confirmer un de ces éléments au client : une validation de transaction ou une restauration.
3. Le serveur miroir renforce le journal sur le disque et retourne un accusé de réception au serveur principal.
4. Dès qu'il reçoit l'accusé de réception du serveur miroir, le serveur principal envoie un message de confirmation au client.

Le mode haute sécurité protège vos données en exigeant leur synchronisation entre deux emplacements. Toutes les transactions validées seront écrites sur le disque du serveur miroir.

Mode Haute sécurité sans basculement automatique

La figure suivante illustre la configuration du mode haute sécurité sans basculement automatique. La configuration implique uniquement les deux partenaires.

Lorsque les partenaires sont connectés et que la base de données est déjà synchronisée, un basculement manuel est possible. Si l'instance du serveur miroir s'arrête, l'instance du serveur principal n'est pas affectée par cet arrêt et s'exécute de manière exposée (à savoir, sans mise en miroir des données). En cas de perte du serveur principal, le miroir est suspendu mais le service peut être manuellement forcé sur le serveur miroir (perte de données possible). Pour plus d'informations, consultez Service forcé (avec possibilité de perte de données).

Mode Haute sécurité avec basculement automatique

Pour garantir une disponibilité optimale, le basculement automatique s'assure que la base de données est toujours desservie après la perte d'un serveur. Le basculement automatique exige que la session dispose d'une troisième instance de serveur (le témoin) résidant de préférence sur un troisième ordinateur. La figure suivante illustre la configuration d'une session en mode haute sécurité avec basculement automatique.

Contrairement aux deux autres, le témoin ne dessert pas la base de données. Le témoin prend simplement en charge le basculement automatique en vérifiant que le serveur principal est activé et qu'il fonctionne. Le serveur miroir lance le basculement automatique uniquement si le miroir et le témoin restent connectés l'un à l'autre après que tous les deux aient été déconnectés du serveur principal.

Lorsque vous définissez un témoin, la session nécessite un quorum, c'est-à-dire une relation entre au moins deux instances de serveur qui permet de rendre disponible la base de données. Pour plus d'informations, consultez Quorum : effets d'un témoin sur la disponibilité de la base de données et Basculement automatique. Pour plus d'informations, consultez Témoin de mise en miroir de base de données.

Le basculement automatique nécessite les conditions suivantes :

• La base de données est déjà synchronisée.
• L'échec survient lorsque les trois instances de serveur sont connectées et le témoin et le serveur miroir sont toujours connectés.

La perte d'un partenaire a les effets suivants :

• Si le serveur principal devient indisponible dans les conditions énoncées ci-avant, il y a basculement automatique. Le serveur miroir devient le serveur principal et il propose sa base de données comme base de données principale.
• Si le serveur principal devient indisponible lorsque ces conditions sont respectées, il est possible de forcer le service (avec perte de données possible). Pour plus d'informations, consultez Service forcé (avec possibilité de perte de données).
• Si le seul serveur miroir devient indisponible, le serveur principal et le serveur témoin continuent de fonctionner.

Si la session perd son témoin, un quorum nécessite l'intervention des deux partenaires. Si l'un des partenaires perd le quorum, les deux partenaires perdent le quorum, et la base de données n'est plus disponible tant que le quorum n'a pas été rétabli. Cet impératif de quorum garantit que, en l'absence d'un témoin, la base de données ne s'exécute jamais de manière exposée, c'est-à-dire sans être mise en miroir.

Remarque :
Si vous pensez que le témoin va rester déconnecté pendant un laps de temps important, nous vous recommandons de le supprimer de votre session jusqu'à ce qu'il devienne disponible.

Voir aussi

Concepts

Sessions de mise en miroir de bases de données
Quorum : effets d'un témoin sur la disponibilité de la base de données
Paramètres Transact-SQL et modes d'opération de mise en miroir de bases de données

Autres ressources

Analyse de la mise en miroir de bases de données

Aide et Informations

Assistance sur SQL Server 2005