Résolution des problèmes de bases de données de disponibilité AlwaysOn lors d’une restauration « en attente » ou d’un état « suspect » dans SQL Server 2012

Résumé

Supposons qu’une base de données de disponibilité qui est défini dans un groupe de disponibilité AlwaysOn passe à un état « suspect » dans Microsoft SQL Server 2012 ou de « restauration en attente ». Si cela se produit sur les réplica principal du groupe de la disponibilité, la disponibilité de la base de données est affectée. Dans ce cas, vous ne peut pas accéder à la base de données par les applications clientes. En outre, vous ne peut pas déplacer ou supprimer la base de données du groupe de disponibilité.

Par exemple, supposons que Microsoft SQL Server est en cours d’exécution et qu’une base de données de disponibilité a l’état de « suspect » ou de « restauration en attente ». Lorsque vous interrogez les vues de gestion dynamique (DMV) au réplica principal en utilisant le script SQL suivant, la base de données peut-être être signalée dans un état NOT_HEALTHY et RECOVERY_PENDING ou dans un état SUSPECT comme suit :

select dc.database_name, d.synchronization_health_desc, d.synchronization_state_desc, d.database_state_descfrom sys.dm_hadr_database_replica_states d join sys.availability_databases_cluster dcon d.group_database_id=dc.group_database_id and d.is_local=1
database_name   synchronization_health_desc    synchronization_state_desc     database_state_desc-------------------- ------------------------------ ------------------------------ ---------------------
<
Database name> NOT_HEALTHY NOT SYNCHRONIZING RECOVERY_PENDING(1 row(s) affected)



En outre, cette base de données peut être signalé comme étant en le pas de synchronisation / récupération en attente ou suspectez un état dans Microsoft SQL Server Management Studio.



Lorsque la base de données est défini dans un groupe de disponibilité, la base de données ne peuvent pas être supprimé ou restauré. Par conséquent, vous devez suivre des étapes spécifiques pour récupérer la base de données et le renvoyer à la production. Cet article décrit les erreurs et les limites d’une base de données de disponibilité qui se trouve dans une « restauration en attente » ou « suspect » d’état et la restauration de la base de données toutes les fonctionnalités d’un groupe de disponibilité.

Plus d'informations

Le contenu suivant présente les erreurs et les limites d’une base de données de disponibilité qui est dans un état « en attente de la récupération » dans diverses situations.

Vous essayez d’exécuter le script SQL suivant afin de restaurer la base de données avec le paramètre de récupération :

restore database <Database name> with recovery

Lorsque vous exécutez ce script, le message d’erreur suivant s’affiche, car la base de données est défini dans un groupe de disponibilité :

Msg 3104, niveau 16, état 1, ligne 1
RESTORE ne peut pas fonctionner sur la base de données '< nom de la base de données >' parce qu’il est configuré pour la mise en miroir de base de données ou a rejoint un groupe de disponibilité. Si vous prévoyez de restaurer la base de données, utilisez ALTER DATABASE pour supprimer la mise en miroir ou à supprimer de la base de données à partir de son groupe de disponibilité.

Msg 3013, niveau 16, état 1, ligne 1
RESTAURER la base de DONNÉES se termine anormalement.



Vous essayez d’exécuter le script SQL suivant pour supprimer la base de données :

drop database <Database name>

Lorsque vous exécutez ce script, le message d’erreur suivant s’affiche, car la base de données est défini dans un groupe de disponibilité :

Msg 3752, niveau 16, état 1, ligne 1
La base de données '< nom de la base de données >' est actuellement lié à un groupe de disponibilité. Suppression de la base de données, vous devez le supprimer à partir du groupe de disponibilité.



Vous essayez d’exécuter le script SQL suivant pour supprimer la base de données du groupe de disponibilité :

alter database <Database name> set hadr off

Lorsque vous essayez d’exécuter ce script, le message d’erreur suivant s’affiche car la base de données de disponibilité auquel appartient le réplica principal :

Msg 35240, niveau 16, état 14, ligne 1
La base de données ' <nom de la base de données>' ne peut pas être joint à ou non connectée à un groupe de disponibilité ' <nom du groupe de disponibilité>'. Cette opération n’est pas pris en charge sur le réplica principal du groupe de disponibilité.


En raison de ce message d’erreur, vous pouvez être astreint à basculer sur la base de données. Une fois la base de données est en cours de basculement, le réplica qui est propriétaire de la base de données de « restauration en attente » est dans le rôle secondaire. Dans ce cas, vous essayez à nouveau d’exécuter le script SQL suivant afin de supprimer la base de données à partir du groupe de disponibilité dans le réplica secondaire :

alter database <Database name> set hadr off

Toutefois, vous ne pouvez pas toujours supprimer la base de données à partir du groupe de disponibilité, et le message d’erreur suivant s’affiche car la base de données est toujours dans un état « en attente de la récupération » :

Msg 921, niveau 16, état 112, ligne 1
La base de données ' <nom de la base de données>' n’a pas encore été récupérée. Patientez et réessayez.


Résolution

Pour résoudre ce problème, utilisez les méthodes suivantes, en fonction de la situation.


Pour résoudre ce problème, effectuez les actions générales suivantes :

  • Supprimer le réplica qui héberge la base de données endommagée lorsque la base de données est dans le rôle secondaire du groupe de disponibilité.

  • Résoudre les problèmes qui ont une incidence sur le système et qui pouvaient avoir contribué à la défaillance de la base de données.

  • Restaurer le réplica dans le groupe de disponibilité.

Pour effectuer ces actions, vous connecter à nouveau réplica principal et puis exécutez le script SQL de « Modifier le groupe de disponibilité » pour supprimer le réplica qui héberge la base de données de disponibilité a échoué. Pour ce faire, procédez comme suit.

Remarque  Ces étapes supposent que le réplica principal héberge tout d’abord la base de données endommagée. Par conséquent, un basculement sur incident doit avoir lieu tout d’abord à effectuer la transition du réplica qui héberge la base de données endommagée dans un rôle secondaire.

  1. La connexion au serveur qui exécute SQL Server et qui héberge le réplica secondaire.

  2. Exécutez le script SQL suivant :

    alter availability group <Availability group name> failover
  3. Exécutez le script SQL suivant pour supprimer le réplica qui héberge la base de données endommagée à partir du groupe de disponibilité :

    alter availability group <Availability group name> remove replica on '<SQL Server node name>'
  4. Résoudre les problèmes sur le serveur qui exécute SQL Server et qui peuvent contribuer à la défaillance de la base de données.

  5. Ajouter le réplica dans le groupe de disponibilité.


Si le réplica principal héberge la base de données endommagée et qu’il est le seul réplica de travail dans le groupe de disponibilité, le groupe de disponibilité doit être supprimée. Une fois le groupe de disponibilité est déposé, votre base de données peut être récupérée à partir d’une sauvegarde ou autres efforts de récupération d’urgence peuvent être appliquées pour restaurer les bases de données et reprendre la production.

Pour supprimer le groupe de disponibilité, annuler le script SQL suivant :

drop availability group <Availability group name>

À ce stade, vous pouvez tenter de récupérer la base de données problématique. Ou, ou vous pouvez restaurer la base de données à partir de la dernière bonne copie de sauvegarde.

Lorsque vous supprimez un groupe de disponibilité, la ressource de port d’écoute est également supprimée et interrompt la connectivité aux bases de données de disponibilité de l’application.

Pour minimiser les interruptions de service, utilisez une des méthodes suivantes pour maintenir la connectivité des applications par le biais de l’écouteur et de supprimer le groupe de disponibilité :

Méthode 1 : Associer le port d’écoute avec un nouveau groupe de disponibilité (rôle) dans le Gestionnaire de Cluster de basculementCette méthode vous permet de maintenir l’écouteur lors de la suppression et nouvelle création du groupe de disponibilité.

  1. Sur l’instance de SQL Server sur lequel l’écouteur de groupe existante disponibilité dirige connexions, créer un groupe de disponibilité vide. Pour simplifier ce processus, utilisez la commande Transact-SQL pour créer un groupe de disponibilité qui n’a aucun réplica secondaire ou une base de données :

    use mastergo
    create availability group ag for replica on 'sqlnode1' with
    (endpoint_url = 'tcp://sqlnode1:5022', availability_mode=asynchronous_commit, failover_mode=manual)
  2. Démarrez le Gestionnaire du Cluster de basculement, puis cliquez sur rôles dans le volet gauche. Dans le volet qui répertorie les rôles, sélectionnez le groupe de disponibilité d’origine.

  3. Dans le volet du milieu bas sous l’onglet ressources , cliquez sur la ressource de groupe de disponibilité, puis cliquez sur Propriétés. Cliquez sur l’onglet dépendances , supprimer la dépendance à l’écouteur, puis cliquez sur OK.

  4. Sous ressources, cliquez avec le bouton droit de la souris sur le port d’écoute, cliquez sur Autres Actions, puis cliquez sur attribuer un autre rôle.

  5. Dans la boîte de dialogue Affecter une Source à un rôle , sélectionnez le nouveau groupe de disponibilité, puis cliquez sur OK.

  6. Dans le volet rôles , sélectionnez le nouveau groupe de disponibilité. Dans le volet du milieu bas, sous l’onglet ressources , vous devez maintenant voir le nouveau groupe de disponibilité et de la ressource de l’écouteur. Avec le bouton droit de la nouvelle ressource de groupe de disponibilité, puis cliquez sur Propriétés.

  7. Cliquez sur l’onglet dépendances , sélectionnez la ressource de l’écouteur dans la zone de liste déroulante, puis cliquez sur OK.

  8. Dans Microsoft SQL Server Management Studio, utilisez l’Explorateur d’objets pour vous connecter à l’instance de SQL Server qui héberge le réplica principal du nouveau groupe de disponibilité. Cliquez sur AlwaysOn de haute disponibilité, cliquez sur le nouveau groupe de disponibilité, puis cliquez sur Disponibilité groupe écouteurs. Vous devriez trouver l’écouteur.

  9. Avec le bouton droit à l’écouteur et cliquez sur type de Propriétés, le numéro de port approprié pour le port d’écoute, puis cliquez sur OK.

Cela permet de garantir que les applications qui utilisent le port d’écoute peuvent utiliser toujours se pour connecter à l’instance de SQL Server qui héberge les bases de données de production sans interruption. Le groupe de disponibilité d’origine peut maintenant être complètement supprimé et recréé. Ou bien, les bases de données et les réplicas peuvent être ajoutés au nouveau groupe de disponibilité.

Important Si vous recréez des groupe de disponibilité d’origine, vous devez réaffecter l’écouteur sur le rôle de groupe de disponibilité, définir la relation entre la nouvelle ressource de groupe de disponibilité et de l’écouteur et le réaffecter à l’écouteur. Pour ce faire, procédez comme suit :

  1. Démarrez le Gestionnaire du Cluster de basculement, puis cliquez sur rôles dans le volet gauche. Dans le volet qui répertorie les rôles, cliquez sur le nouveau groupe de disponibilité qui héberge le port d’écoute.

  2. Dans le volet central de bas sous l’onglet ressources , cliquez sur le port d’écoute, cliquez sur Autres Actions, puis cliquez sur attribuer à un autre rôle. Dans la boîte de dialogue, choisissez le groupe de disponibilité de nouveau créé et puis cliquez sur OK.

  3. Dans le volet rôles , cliquez sur le groupe de disponibilité recréé. Dans le volet du milieu inférieur, sous l’onglet ressources , vous devez maintenant voir le groupe de disponibilité recréé et la ressource de l’écouteur. Avec le bouton droit de la ressource de groupe de disponibilité de nouveau créé, puis cliquez sur Propriétés.

  4. Cliquez sur l’onglet dépendances , sélectionnez la ressource de l’écouteur dans la zone de liste déroulante, puis cliquez sur OK.

  5. Dans SQL Server Management Studio, utilisez l’Explorateur d’objets pour se connecter à l’instance de SQL Server qui héberge le réplica principal du groupe de disponibilité recréé. Cliquez sur AlwaysOn de haute disponibilité, cliquez sur le nouveau groupe de disponibilité, puis cliquez sur Disponibilité groupe écouteurs. Vous devriez trouver l’écouteur.

  6. Avec le bouton droit à l’écouteur et cliquez sur Propriétés, tapez le numéro de port approprié pour le port d’écoute, puis cliquez sur OK.

Méthode 2 : Associer le port d’écoute avec un existant SQL Server avec basculement en cluster Instance (SQLFCI)

Si vous hébergez votre groupe de disponibilité sur une Instance de cluster des basculement SQL Server (SQLFCI), vous pouvez associer la ressource de l’écouteur en cluster avec le groupe de ressource en clusters SQLFCI tandis que vous supprimez puis recréez le groupe de disponibilité.

  1. Démarrez le Gestionnaire du Cluster de basculement, puis cliquez sur rôles dans le volet gauche.

  2. Dans le volet qui répertorie les rôles, sélectionnez le groupe de disponibilité d’origine.

  3. Dans le volet central de bas sous l’onglet ressources , cliquez sur la ressource de groupe de disponibilité, puis cliquez sur Propriétés.

  4. Cliquez sur l’onglet dépendances , supprimer la dépendance à l’écouteur, puis cliquez sur OK.

  5. Dans le volet central de bas sous l’onglet ressources , cliquez avec le bouton droit de la souris sur le port d’écoute, cliquez sur Autres Actions puis attribuez un autre rôle.

  6. Dans la boîte de dialogue Affecter les ressources au rôle , cliquez sur l’instance SQL Server FCI, puis cliquez sur OK.

  7. Dans le volet rôles , sélectionnez le groupe de basculement en cluster Instance (SQLFCI) pour SQL Server. Dans le volet du milieu inférieur, sous l’onglet ressources , vous devez maintenant voir la nouvelle ressource de port d’écoute.

Cela permet de garantir que les applications qui utilisent le port d’écoute peuvent toujours l’utiliser pour se connecter à l’instance de SQL Server qui héberge les bases de données de production sans interruption. Le groupe de disponibilité d’origine peut maintenant être complètement supprimé et recréé. OU bien, les bases de données et les réplicas peuvent être ajoutés au nouveau groupe de disponibilité.

Important Une fois le groupe de disponibilité est recréé, réaffecter l’écouteur sur le rôle de groupe de disponibilité. Puis configurez l’interdépendance entre la nouvelle ressource de groupe de disponibilité et de l’écouteur et le ré-affecter le port à l’écoute :

  1. Démarrez le Gestionnaire du Cluster de basculement, puis cliquez sur rôles dans le volet gauche.

  2. Dans le volet qui répertorie les rôles, cliquez sur le rôle de l’Instance de cluster de basculement SQL d’origine.

  3. Dans le volet du milieu inférieur, sous l’onglet ressources , cliquez sur le port d’écoute, cliquez sur Autres Actions, puis cliquez sur attribuer à un autre rôle.

  4. Dans la boîte de dialogue, cliquez sur le groupe de disponibilité de nouveau créé, puis cliquez sur OK.

  5. Dans le volet rôles , sélectionnez le nouveau groupe de disponibilité.

  6. Sous l’onglet ressources , vous devriez voir le nouveau groupe de disponibilité et de la ressource de l’écouteur. Avec le bouton droit de la nouvelle ressource de groupe de disponibilité, puis cliquez sur Propriétés.

  7. Cliquez sur l’onglet dépendances , sélectionnez la ressource de l’écouteur dans la zone de liste déroulante, puis cliquez sur OK.

  8. Dans SQL Server Management Studio, utilisez l’Explorateur d’objets pour vous connecter à l’instance de SQL Server qui héberge le réplica principal du nouveau groupe de disponibilité.

  9. Cliquez sur AlwaysOn de haute disponibilité, cliquez sur le nouveau groupe de disponibilité, puis cliquez sur Disponibilité groupe écouteurs. Vous devriez trouver l’écouteur.

  10. Avec le bouton droit à l’écouteur et cliquez sur Propriétés, tapez le numéro de port approprié pour le port d’écoute, puis cliquez sur OK.

Méthode 3 : Supprimer le groupe de disponibilité et puis recréer le groupe de disponibilité et l’écouteur portant le même nom de port d’écoute

Cette méthode provoque une panne de petite pour les applications qui sont actuellement connectés, car le groupe de disponibilité et d’écoute sont ignorés et puis créées à nouveau :

  1. Supprimer le groupe de disponibilité.

    Remarque Cela va également supprimer l’écouteur.

  2. Créer immédiatement un groupe de disponibilité de vide qui inclut la définition de l’écouteur, sur le même serveur qui héberge les bases de données de production. Par exemple, supposons que votre écouteur de groupe de disponibilité est « aglisten ». L’instruction Transact-SQL suivante crée un groupe de disponibilité sans base de données principale ou secondaire, mais elle crée également un écouteur nommé « aglisten ». Applications peuvent utiliser ce port d’écoute pour se connecter.

    use mastergo
    create availability group ag for replica on 'sqlnode1' with
    endpoint_url = 'tcp://sqlnode1:5022', availability_mode=asynchronous_commit, failover_mode=manual)
    listener 'aglisten' (with ip ((n'11.0.0.25', n'255.0.0.0')), port=1433)go
  3. Restaurer la base de données endommagée. Puis ajoutez et le réplica secondaire vers le groupe de disponibilité.


Besoin d’aide ?

Développez vos compétences
Découvrez des formations
Accédez aux nouvelles fonctionnalités en avant-première
Rejoindre Microsoft Insider

Ces informations vous ont-elles été utiles ?

Nous vous remercions pour vos commentaires.

Merci pour vos commentaires. Il serait vraisemblablement utile pour vous de contacter l’un de nos agents du support Office.

×