Résoudre les problèmes liés à une base de données de groupe de disponibilité en état de restauration

Cet article vous aide à résoudre les problèmes d’une base de données de groupe de disponibilité en état de restauration.

Qu’est-ce qui rétablit l’état ?

L’état de restauration se produit lorsque le serveur secondaire doit annuler les modifications qu’il a déjà appliquées afin de revenir en arrière de la synchronisation avec le serveur principal.

Le ou les réplicas principaux et secondaires du groupe de disponibilité restent dans un état connecté pendant l’opération normale afin que les modifications apportées au réplica principal soient synchronisées activement avec les réplicas secondaires.

Pendant les basculements, cet état connecté est rompu. Une fois le nouveau réplica principal mis en ligne, la connectivité est rétablie entre le réplica principal et les réplicas secondaires. Pendant cet état connecté initial, un point de récupération courant est négocié dans lequel le nouveau serveur secondaire doit démarrer la récupération afin qu’elle soit synchronisée avec le serveur principal.

Si une transaction volumineuse s’exécute au moment du basculement, le nouveau journal de base de données secondaire est à l’avance de la base de données réplica principale. Le nouveau point de récupération commun négocié nécessite que le réplica secondaire reçoive des pages du réplica principal afin qu’il soit dans un état où la synchronisation peut reprendre. Le processus de restauration est également appelé « Annuler de rétablissement ».

Le processus de restauration est intrinsèquement lent, se produit souvent, et généralement de petites transactions qui déclenchent l’état de restauration sont à peine remarquées. L’état de restauration est souvent remarqué lorsque le basculement interrompt une transaction volumineuse, ce qui entraîne l’envoi de nombreuses pages du serveur principal vers la base de données secondaire pour rétablir l’état récupérable de la base de données du réplica secondaire.

Symptômes et effet d’une base de données de groupe de disponibilité en état de restauration

Lorsqu’une base de données est en état de restauration sur le réplica secondaire, la base de données n’est pas synchronisée et ne reçoit donc pas de modifications du réplica principal. Une perte soudaine de la base de données sur le réplica principal peut entraîner une perte de données.

Rapports de tableau de bord Always On ne synchronisant pas sur le serveur principal

Après le basculement d’un groupe de disponibilité, vous pouvez observer que le serveur secondaire est signalé comme ne se synchronisant pas pendant que le basculement a réussi. Le tableau de bord Always On signale qu’il ne se synchronise pas sur le serveur principal et rétablit sur le serveur secondaire.

Rapports de tableau de bord Always On ne synchronisant pas sur le serveur principal	Le tableau de bord Always On signale la restauration sur le serveur secondaire

Les vues de gestion dynamique Always On ne synchronisent pas sur le serveur principal

Lorsque vous interrogez les vues de gestion dynamique (DMV) des groupes de disponibilité Always On (AGs) suivantes sur le serveur principal, la base de données est dans l’état NOT SYNCHRONIZING .

SELECT DISTINCT ar.replica_server_name, drcs.database_name, drs.database_id, drs.synchronization_state_desc, drs.database_state_desc
FROM sys.availability_replicas ar 
JOIN sys.dm_hadr_database_replica_states drs 
ON ar.replica_id=drs.replica_id 
JOIN sys.dm_hadr_database_replica_cluster_states drcs
ON drs.group_database_id=drcs.group_database_id

Lorsque vous interrogez les DMV sur la base de données secondaire, la base de données du groupe de disponibilité est à l’état REVERTING .

Les charges de travail en lecture seule et de création de rapports ne parviennent pas à accéder à la base de données secondaire

Pendant que la base de données secondaire est rétablie, elle n’est pas accessible ou interrogée. Ces charges de travail en lecture seule sont hors connexion et interrompues. Selon la durée pendant laquelle la base de données est en état de restauration, il peut être nécessaire de rediriger ces charges de travail vers un autre réplica secondaire ou le réplica principal si ces charges de travail sont critiques pour l’entreprise.

Si vous disposez d’une charge de travail en lecture seule, comme une charge de travail de création de rapports routée vers le réplica secondaire, ces lots peuvent échouer avec le message 922 :

Msg 922, Level 14, State 1, Line 2 Database 'agdb' est récupéré. Patientez jusqu'à ce que la récupération soit terminée.

Une application qui tente de se connecter à la base de données réplica secondaire en état de restauration ne parvient pas à se connecter et génère l’erreur 18456 :

2023-01-26 13:01:13.100 Erreur d’ouverture de session : 18456, Gravité : 14, État : 38. 2023-01-26 13:01:13.100 Connexion de connexion a échoué pour l’utilisateur «< UserName> ». Motif : Échec de l’ouverture de la base de données explicitement spécifiée « agdb ». [CLIENT : <ordinateur> local]

Cette erreur peut également être signalée dans le journal des erreurs SQL Server si les connexions ayant échoué sont auditées.

Estimer le temps restant dans l’état de restauration

Utilisez l’une des méthodes suivantes pour estimer le temps restant dans l’état de restauration :

Utiliser la session AlwaysOn_health XEvent

Le journal de diagnostic d’événements étendu AlwaysOn_health a un événement hadr_trace_message qui signale la progression de l’état de restauration toutes les cinq minutes.

Connectez-vous au réplica secondaire à l’aide de l’Explorateur d’objets SQL Server Management Studio (SSMS) et explorez la gestion, les événements étendus, puis les sessions. Cliquez avec le bouton droit sur l’événement AlwaysOn_health, puis sélectionnez Watch Live Data. Vous devez obtenir une nouvelle fenêtre à onglets signalant l’état actuel de la restauration de l’opération. L’état est signalé toutes les cinq minutes via l’événement hadr_trace_message , et le pourcentage terminé d’opération de restauration est signalé.

Le journal des erreurs SQL Server sur le réplica secondaire n’est pas beaucoup d’aide lors de l’estimation de l’achèvement de la restauration. À partir de l’image suivante, vous pouvez observer de 10:08 à 11:03 tout en rétablissant l’état, peu est signalé. Une fois que le réplica secondaire a reçu toutes les pages du réplica principal, il est maintenant en mesure de restaurer la transaction qui s’exécutait sur le serveur principal d’origine qui a déclenché l’état de restauration. La récupération s’exécute de 11:03 à 11:05. Peu de temps après la récupération, la base de données doit commencer à se synchroniser avec le réplica principal et rattraper toutes les modifications apportées au serveur principal pendant que la base de données secondaire était en état de restauration.

Surveiller la restauration du temps d’achèvement à l’aide de Analyseur de performances

Surveillez la progression de l’état de restauration à l’aide des compteurs de performances SQL Server :Database Replica :Total Log Requiring Undo et SQL Server :Database Replica :Log Remaining for Undo et choisissez la base de données du groupe de disponibilité pour l’instance. Dans l’exemple de la capture d’écran suivante, le nombre total de journaux nécessitant une annulation est signalé comme étant de 56,3 Mo, et le journal restant pour l’annulation passe lentement à 0 qui signale la progression de la restauration.

Quelles sont vos autres options que d’attendre ?

Microsoft vous recommande d’estimer le délai d’achèvement de la restauration de l’état.

Ajouter un réplica secondaire à un groupe de disponibilité

S’il n’existe que deux réplicas dans le groupe de disponibilité, si possible, ajoutez un autre réplica secondaire qui peut fournir une haute disponibilité et une redondance et synchroniser activement avec le réplica principal pendant que l’autre secondaire termine la restauration.

Comment résoudre les charges de travail en lecture seule défaillantes

Étant donné que les bases de données réplica secondaires en restauration sont inaccessibles, les charges de travail en lecture seule échouent. Mettez à jour la table de routage des intentions de lecture pour router le trafic vers le réplica principal ou vers un autre réplica secondaire jusqu’à ce que la base de données de réplica secondaire affectée termine le processus de restauration.

Éviter de rétablir l’état : surveiller les transactions volumineuses

Si vous observez cet état fréquemment pendant les basculements planifiés, implémentez une procédure qui vérifie les transactions volumineuses avant les basculements. La requête suivante signale l’heure de début de la transaction et l’heure actuelle de toutes les transactions ouvertes sur le système et fournit la mémoire tampon d’entrée des transactions.

SELECT tat.transaction_begin_time, getdate() AS 'current time', es.program_name, es.login_time, es.session_id, tst.open_transaction_count, eib.event_info
FROM sys.dm_tran_active_transactions tat
JOIN sys.dm_tran_session_transactions tst ON tat.transaction_id=tst.transaction_id
JOIN sys.dm_exec_sessions es ON tst.session_id=es.session_id 
CROSS APPLY sys.dm_exec_input_buffer(es.session_id, NULL) eib WHERE es.is_user_process = 1
ORDER BY tat.transaction_begin_time ASC