La base de données SQL Server AlwaysOn est bloquée en mode de non synchronisation / récupération après la mise à niveau. Erreur: impossible d'ouvrir la base de données '…' version 782


10

Lors du test d'une mise à niveau de SQL Server 2014 SP1 (12.0.4422.0) vers SQL Server 2016 CTP 3.2 (13.0.900.73), je suivais le processus de mise à jour recommandé et suis tombé sur un problème où la base de données ne démarre pas sur l'ancien serveur principal après le basculement au secondaire mis à jour. Notre configuration est une réplique principale et une réplique secondaire unique, et les étapes que j'ai effectuées étaient les suivantes:

  1. Supprimer le basculement automatique sur le réplica secondaire à validation synchrone
  2. Mettre à niveau les instances de serveur secondaire vers une nouvelle version
  3. Basculer manuellement vers la réplique secondaire
  4. Vérifiez que les bases de données sont en ligne sur la nouvelle réplique principale
  5. Mettre à niveau la réplique précédente précédente vers la nouvelle version

La mise à niveau du secondaire et le basculement pour en faire le primaire ont fonctionné exactement comme prévu. Mais après la mise à niveau de la réplique précédemment principale, j'ai remarqué que les bases de données sur elle étaient répertoriées dans SSMS comme Non Synchronizing / In Recovery . Essayer également d'y accéder générerait un message d'erreur:

La base de données ... n'est pas accessible. (ObjectExplorer)

Vérification à travers les journaux SQL Server que j'ai vus

Impossible d'ouvrir la base de données '...' version 782. Mettez à niveau la base de données vers la dernière version.

L'interrogation de la table master..sysdatabases a montré qu'il s'agissait bien d'une ancienne version et qu'elle n'avait pas été mise à jour lors de la mise à niveau:

Version sysdatabases SSMS

Malheureusement, les journaux n'ont pas indiqué pourquoi il n'a pas été mis à jour, et le tableau de bord des groupes de disponibilité n'a donné qu'un avertissement générique indiquant que l' état de synchronisation des données d'une base de données de disponibilité n'est pas sain sans raison.

J'ai essayé d'utiliser TSQL pour détacher les bases de données ou les mettre hors ligne pour les "mettre à jour", mais comme elles font partie de SQL AG, ces commandes ne fonctionnent pas.

Comment puis-je mettre à niveau la base de données vers la dernière version lorsqu'elle fait partie d'un SQL AG?

Réponses:


10

Après avoir fouillé dans SSMS pendant un certain temps, j'ai remarqué que sur la réplique secondaire, il y avait une icône de pause à côté des bases de données de disponibilité. Le primaire avait montré que les deux étaient "verts", mais il y avait une option sur le secondaire pour reprendre le mouvement des données . J'ai repris la première base de données et immédiatement le message d'état In Recovery a été supprimé. Une minute plus tard, il est passé de Pas de synchronisation à Synchronisé, et tout a fonctionné comme prévu.

Voici une capture d'écran des bases de données AG après avoir corrigé "Patch", mais avant de corriger la base de données de test:

Reprendre le mouvement des données sur SQL AG

Notez que vous pouvez également utiliser TSQL sur le secondaire pour reprendre la réplication sur plusieurs bases de données en même temps:

ALTER DATABASE [Patch] SET HADR RESUME;
ALTER DATABASE [test] SET HADR RESUME;
GO

1
Savez-vous ce qui a causé la pause de la réplication? et puis-je savoir depuis quand la réplication a été interrompue?
JohnG
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.