web-dev-qa-db-fra.com

Impossible de supprimer la base de données du groupe AlwaysOn distribué sur le cluster Windows secondaire

Nous avons distribué AG sur deux clusters de fenêtres.

  • Clus01 - A un AG configuré sans DB à l'intérieur (AG1)
  • Clus02 - A un AG configuré sans DB à l'intérieur (AG2)
  • Clus01 - Dispose d'un DistAG configuré avec AG1 (principal) et AG2 (secondaire)

Nous

  • Rejoint Clus02 au DistAG
  • Ajout d'une base de données à AG1 sur Clus01
  • Restauré cette base de données en restauration vers AG2
  • Ajout de cette base de données à AG2 sur Clus02 (s'affiche comme principal, mais est vraiment secondaire dans le DistAG)

DB sur Clus02 fonctionnait maintenant comme prévu ... toutes les mises à jour sur DB sur Clus01 utiliseraient DistAG pour mettre à jour Clus02 DB.

Nous actualisons souvent cet environnement en direct (il s'agit d'un préprod). nous devons donc restaurer la base de données sur CLus01.

Pour nos AG normaux, nous supprimons simplement la base de données de CLUS01, restaurons en CLUS01, sauvegardons et restaurons en CLUS02 et rejoignons AG de nouveau.

Pour DistAG, je ne peux pas

  1. Supprimez la base de données d'AG2 sur CLUS02.

    ALTER AVAILABILITY GROUP [AG_G2CoreReporting]
REMOVE DATABASE [Genesis];
GO

    Nous obtenons l'erreur

    Msg 41190, niveau 16, état 8, groupe de disponibilité de ligne 6 "AG2" n'a pas pu traiter la commande remove-database. Le réplica de disponibilité locale n'est pas dans un état qui pourrait traiter la commande. Vérifiez que le groupe de disponibilité est en ligne et que le réplica de disponibilité local est le réplica principal, puis relancez la commande.

  2. Supprimez la base de données d'AG1 sur CLUS01. DB sur AG2 sur CLUS02 entre dans un état non synchronisé et je ne peux pas supprimer (même erreur que ci-dessus), donc je ne peux pas restaurer DB par dessus.

  3. Supprimez la réplique sur le DistAG en exécutant sur CLUS01

    ALTER AVAILABILITY GROUP [DistAG]
REMOVE REPLICA ON N'AG2';

    Nous obtenons l'erreur

    Msg 15151, niveau 16, état 1, ligne 5 Impossible de modifier le groupe de disponibilité "AG2", car il n'existe pas ou vous n'avez pas l'autorisation.

Y a-t-il quelqu'un qui sait comment rafraîchir un environnement avec DistAG sans avoir à supprimer tout DistAG et à le configurer à nouveau?

sql-serveravailability-groupsdistributed-availability-groups
4
DJSQL

Y a-t-il quelqu'un qui sait comment rafraîchir un environnement avec DistAG sans avoir à supprimer tout DistAG et à le configurer à nouveau?

La suppression et la recréation seront votre meilleur pari dans l'implémentation actuelle ... bien que je soutienne la nécessité d'une base de données dans un groupe de disponibilité répartie qui doit être actualisée chaque jour.

La seule autre option consiste à faire basculer le groupe de disponibilité distribué après la suppression de la base de données du serveur principal global afin que le redirecteur devienne le nouveau serveur principal global. Ensuite, vous pourrez supprimer la base de données du deuxième groupe de disponibilité (désormais principal). Cette approche est moins attrayante en raison de la suppression des connexions, par rapport à l'approche de suppression + ajout que vous avez déjà, qui conservera les connexions au serveur principal global actuel.

2
Sean Gallardy

Vous pouvez utiliser l'instruction ci-dessous pour supprimer la base de données de "DistAG".

Exécutez l'instruction ci-dessous sur le nœud principal de "DistAG".

ALTER DATABASE Genesis SET HADR OFF;

Une fois que vous avez exécuté l'instruction ci-dessus, l'état de la base de données passe en mode de restauration, puis vous pouvez supprimer la base de données.

3
HMB