Sessions de mise en miroir de bases de données
La mise en miroir de bases de données intervient dans le contexte d'une session de mise en miroir de bases de données. Cette rubrique suppose que vous connaissez les rôles principal, miroir et témoin, les modes de fonctionnement et le basculement de rôle dans le cadre de la mise en miroir de bases de données. Pour plus d'informations, consultez Présentation de la mise en miroir de bases de données.
Lorsque la base de données miroir est prête et les instances de serveurs sont configurées, le propriétaire de la base de données peut démarrer la mise en miroir de bases de données. Dès le début de la mise en miroir, chaque partenaire met à jour dans sa base de données les informations d'état concernant cette base de données et concernant l'autre partenaire et le témoin, le cas échéant. Grâce à ces informations d'état, les instances de serveur peuvent conserver une relation connue sous le nom de session de mise en miroir de bases de données. Pendant tout le déroulement d'une session de mise en miroir de bases de données, les instances de serveur s'analysent mutuellement. Les informations d'état sont gérées jusqu'à ce que le propriétaire de la base de données arrête la session. Pour plus d'informations, consultez États de la mise en miroir et Surveillance de la mise en miroir de bases de données.
Au début d'une session de mise en miroir de bases de données, le serveur miroir identifie le numéro séquentiel dans le journal du dernier journal des transactions appliqué sur la base de données miroir, puis il demande au serveur principal le journal des transactions de toutes les transactions postérieures, le cas échéant. En réponse, le serveur principal envoie au serveur miroir tous les enregistrements de journal actif accumulés depuis le dernier journal restauré dans la base de données miroir ou envoyé au serveur miroir. Tout journal non envoyé accumulé sur le disque de journal de la base de données principale porte le nom de file d'attente d'envoi.
Le serveur miroir écrit immédiatement le journal entrant sur le disque, où il est conservé jusqu'à ce qu'il soit appliqué à la base de données miroir. Le journal en attente sur le disque du miroir porte le nom de file d'attente de restauration par progression. La quantité de journal non restauré en attente dans la file d'attente de restauration par progression est un indicateur de la durée nécessaire pour basculer vers la base de données miroir. Pour plus d'informations, consultez Estimation de l'interruption de service au cours d'un basculement de rôle.
Le serveur principal continue de mettre la base de données principale à la disposition des clients et des connexions clientes. Une fois que la mise en miroir a commencé, chaque fois qu'un client met à jour la base de données principale, lors de l'écriture de la transaction dans le journal de la base de données principale, le serveur principal envoie également cet enregistrement de journal au serveur miroir. Là, le serveur miroir écrit immédiatement l'enregistrement de journal sur le disque en tant que dernier enregistrement dans la file d'attente de restauration par progression.
En arrière-plan, en commençant par l'enregistrement de journal le plus ancien, le serveur miroir rétablit le journal sur la base de données miroir, enregistrement par enregistrement, aussi rapidement que possible. Le rétablissement du journal implique l'application des enregistrements de journal en attente à la base de données miroir dans l'ordre, en commençant par l'enregistrement le plus ancien. Chaque enregistrement de journal est rétabli une seule et unique fois. Lorsque le serveur miroir rétablit le journal, la base de données miroir est restaurée par progression de manière continue. Lorsque le serveur principal tronque ou réduit le journal de la base de données principale, le serveur miroir réduit également le journal au même point dans le flux des journaux.
En général, le rétablissement permet à la base de données miroir de rattraper rapidement le retard par rapport à la base de données principale. Le fait que la base de données miroir rattrape ou non complètement la base de données principale dépend du mode de fonctionnement de la session. En mode haute sécurité synchrone, le serveur principal ne confirme les nouvelles transactions que lorsqu'elles sont écrites sur le disque de journal du serveur miroir. Une fois que les enregistrements de journal accumulés ont été envoyés au serveur miroir, la base de données miroir devient synchronisée avec la base de données principale.
Durant une session, si le serveur principal est dans l'incapacité d'envoyer immédiatement chaque enregistrement de journal, les enregistrements de journal non envoyés s'accumulent dans la file d'attente d'envoi. En mode haute sécurité synchrone, après la synchronisation, le nouveau journal non envoyé s'accumule uniquement lorsque la mise en miroir est interrompue ou suspendue. En mode hautes performances asynchrone, en revanche, le journal non envoyé s'accumule chaque fois que le serveur miroir prend du retard durant la mise en miroir et lorsque la mise en miroir est interrompue ou suspendue. La quantité de journal non envoyé est un indicateur de la perte de données possible en cas de défaillance du serveur principal.
[!REMARQUE]
Si le rétablissement échoue, le serveur miroir suspend la session en attribuant à la base de données l'état SUSPENDED. Le propriétaire de la base de données doit résoudre le problème avant de redémarrer la session.
Sessions simultanées
Une instance de serveur peut participer à plusieurs sessions simultanées de mise en miroir de bases de données (une par base de données en miroir) avec des instances de serveur identiques ou différentes. Souvent, une instance de serveur assume la fonction exclusive de partenaire ou de témoin dans toutes ses sessions de mise en miroir de bases de données. Toutefois, chaque session étant indépendante des autres sessions, une instance de serveur peut jouer le rôle de partenaire dans certaines sessions et celui de témoin dans d'autres sessions. Par exemple, considérez les quatre sessions suivantes parmi trois instances de serveur (SSInstance_1, SSInstance_2 et SSInstance_3). Chaque instance de serveur assume le rôle de partenaire dans certaines sessions et de témoin dans d'autres :
Instance de serveur |
Session pour la base de données A |
Session pour la base de données B |
Session pour la base de données C |
Session pour la base de données D |
|---|---|---|---|---|
SSInstance_1 |
Témoin |
Partenaire |
Partenaire |
Partenaire |
SSInstance_2 |
Partenaire |
Témoin |
Partenaire |
Partenaire |
SSInstance_3 |
Partenaire |
Partenaire |
Témoin |
Témoin |
L'illustration suivante présente deux instances de serveurs qui participent en tant que partenaires à deux sessions de mise en miroir. Une session concerne une base de données appelée Db_1 et l'autre session concerne une base de données appelée Db_2.
.gif "Deux instances de serveur dans deux sessions simultanées")
Chaque base de données est indépendante des autres. Par exemple, une instance de serveur peut initialement être le serveur miroir de deux bases de données. Si l'une de ces bases de données bascule, l'instance de serveur devient le serveur principal de la base de données ayant basculé tout en restant le serveur miroir de l'autre base de données.
Imaginons maintenant une instance de serveur qui est le serveur principal de deux bases de données ou plus exécutées en mode haute sécurité avec basculement automatique. En cas de défaillance de l'instance de serveur, chaque base de données bascule automatiquement sur sa base de données miroir respective.
Lorsque vous configurez une instance de serveur afin qu'elle soit à la fois partenaire et témoin, assurez-vous que le point de terminaison de la mise en miroir de la base de données prend en charge les deux rôles (pour plus d'informations, consultez Point de terminaison de mise en miroir de bases de données). Qui plus est, vérifiez que le système dispose de ressources suffisantes pour réduire les conflits de ressources.
[!REMARQUE]
Comme les bases de données mises en miroir sont indépendantes les unes des autres, elles ne peuvent pas basculer en tant que groupe.
Threads créés pour une session de mise en miroir de bases de données
Les types de threads qu'une instance de serveur crée pour une session de mise en miroir de bases de données dépendent en partie des rôles de mise en miroir assumés par l'instance de serveur. Une session donnée possède tous ou certains des threads suivants :
Un thread global pour les communications de mise en miroir de bases de données. Ce thread est démarré par Service Broker.
Si l'instance de serveur joue le rôle de serveur partenaire de mise en miroir (qu'il s'agisse du serveur principal ou du serveur miroir) :
Un thread par base de données mise en miroir pour le traitement d'événement.
Un thread par base de données mise en miroir pour les tâches asynchrones (tels que l'envoi de journal ou l'écriture de journal) qui autrement bloqueraient le thread d'événement.
Chaque fois que l'instance joue le rôle de serveur miroir :
Un thread de gestionnaire de phase de restauration par progression, qui soumet le journal pour la phase de restauration par progression, effectue la lecture de page anticipée, la réacquisition de verrou, et ainsi de suite.
Dans SQL Server Standard, un thread de phase de restauration par progression par base de données miroir ou, dans SQL Server Enterprise, un thread de phase de restauration par progression par base de données miroir tous les quatre processeurs. Ces threads effectuent la phase de restauration par progression de journal réelle.
Si l'instance joue le rôle de témoin :
- Un thread global pour traiter les messages de témoin pour toutes les sessions de mise en miroir dans lesquelles l'instance joue le rôle de témoin.
Éléments requis pour une session de mise en miroir de bases de données
Pour pouvoir lancer une session de mise en miroir, l'administrateur système ou le propriétaire de la base de données doit créer la base de données miroir, définir les points de terminaison et les connexions. Dans certains cas, il doit également créer et configurer des certificats. Pour plus d'informations, consultez Configuration de la mise en miroir d'une base de données.
La création d'une base de données miroir requiert au minimum la réalisation d'une sauvegarde complète de la base de données principale puis d'une sauvegarde du journal, ainsi que la restauration de ces deux sauvegardes sur l'instance du serveur miroir, en utilisant WITH NORECOVERY. De plus, avant de démarrer la mise en miroir, si des sauvegardes du journal supplémentaires sont effectuées après la sauvegarde du journal requise, vous devez également appliquer manuellement chacune de ces sauvegardes supplémentaires (toujours à l'aide de WITH NORECOVERY). Une fois la dernière sauvegarde du journal appliquée, vous pouvez démarrer la mise en miroir. Pour plus d'informations, consultez Préparation d'une base de données miroir pour la mise en miroir.
Effets de la suspension d'une session sur le journal des transactions du serveur principal
À tout moment, le propriétaire d'une base de données peut suspendre une session. La suspension conserve l'état de la session tout en supprimant la mise en miroir. Lorsqu'une session est suspendue, le serveur principal n'envoie aucun nouvel enregistrement du journal au serveur miroir. Tous ces enregistrements restent actifs et s'accumulent dans le journal des transactions de la base de données principale. Tant qu'une session de mise en miroir de bases de données demeure suspendue, le journal des transactions ne peut pas être tronqué. Par conséquent, si la session de mise en miroir de bases de données est suspendue trop longtemps, le journal peut arriver à saturation.
Pour plus d'informations, consultez Suspension et reprise de la mise en miroir de bases de données.
Connexions clientes
La prise en charge des connexions clientes pour les sessions de mise en miroir de bases de données est proposée par le fournisseur de données Microsoft .NET pour SQL Server. Pour plus d'informations, consultez Connexions de clients à une base de données mise en miroir.
Voir aussi