Résoudre les problèmes d’une base de données de groupe de disponibilité en état de rétablissement

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

Qu’est-ce que le rétablissement de l’état ?

Le rétablissement de l’état se produit lorsque le serveur secondaire doit annuler les modifications qu’il a déjà appliquées afin de revenir à la synchronisation avec le serveur principal.

Les réplica principales et secondaires du groupe de disponibilité restent connectées pendant le fonctionnement normal, de sorte que les modifications apportées au réplica principal sont activement synchronisées avec les réplica secondaires.

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

Si une transaction volumineuse est en cours d’exécution au moment du basculement, le nouveau journal de base de données secondaire est en avance sur la base de données réplica primaire. Le nouveau point de récupération commun négocié nécessite que le réplica secondaire reçoive les pages de l’réplica primaire afin qu’il soit dans un état où la synchronisation peut reprendre. Le processus de rétablissement est également appelé « Annuler de rétablir ».

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

Symptômes et effet d’une base de données de groupe de disponibilité dans un état de rétablissement

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

Always On tableau de bord signale l’état Non synchronisation sur le serveur principal

Après le basculement d’un groupe de disponibilité, vous pouvez observer que la base de données secondaire est signalée comme n’étant pas synchronisée pendant que le basculement a réussi. Le tableau de bord Always On indique Non synchronisation sur le serveur principal et Rétablissement sur le serveur secondaire.

Always On tableau de bord signale l’état Non synchronisation sur le serveur principal	Always On tableau de bord signale la restauration sur la base de données secondaire

Always On rapports de gestion dynamique ne synchronisant pas sur le serveur principal

Lorsque vous interrogez les Always On vues de gestion dynamique (DMV) de groupes de disponibilité (AG) suivantes sur la base de données principale, 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 vues de gestion dynamique 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 les charges de travail 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 en cours de restauration, 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 à l’état de rétablissement, 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 avez 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, Niveau 14, État 1, Ligne 2 La base de données « agdb » est en cours de récupération. Attendre la fin de la récupération.

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

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

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

Estimer le temps restant dans l’état de rétablissement

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

Utiliser la session XEvent AlwaysOn_health

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

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

Remarque

L’événement hadr_trace_message étendu a été ajouté aux dernières mises à jour cumulatives dans SQL Server 2019 et versions ultérieures. Vous devez exécuter les dernières mises à jour cumulatives pour observer cet événement étendu dans la session d’événements AlwaysOn_health étendus.

Le journal des erreurs SQL Server sur le réplica secondaire n’est pas très utile lors de l’estimation de l’achèvement de la restauration. À partir de l’image suivante, vous pouvez observer de 10 :08 à 11 :03 alors que l’état de rétablissement est peu signalé. Une fois que le serveur secondaire a reçu toutes les pages de la réplica primaire, il est désormais en mesure de restaurer la transaction qui s’exécutait sur le serveur principal d’origine qui a déclenché l’état de rétablissement. La récupération s’exécute de 11 :03 à 11 :05. Peu de temps après la fin de 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 à la base de données primaire alors 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 rétablissement à l’aide des compteurs de performances SQL Server:D abase réplica :Journal total nécessitant une annulation et réplica SQL Server:D atabase :Journal restant pour Annuler, puis 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 , ce qui signale la progression de la restauration.

Quelles sont vos autres options en dehors de l’attente ?

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’y a 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 se synchroniser activement avec le réplica principal pendant que l’autre réplica secondaire se termine.

Importante

Ne basculez pas vers un réplica dont la ou les bases de données sont à l’état de rétablissement. Cela peut entraîner une base de données inutilisable qui nécessite une restauration à partir d’une sauvegarde. Ne redémarrez pas le réplica instance secondaire, cela n’accélérera pas ce processus et risque de compromettre l’état de la base de données secondaire réplica en état de restauration.

Comment résoudre les échecs des charges de travail en lecture seule

Étant donné que les bases de données réplica secondaires lors de la restauration sont inaccessibles, les charges de travail en lecture seule échouent. Mettez à jour la table de routage de l’intention de lecture pour router le trafic vers l’réplica primaire ou vers un autre réplica secondaire jusqu’à ce que la base de données 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 indique 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