Mettre à niveau les réplicas de groupe de disponibilité

S'applique à :SQL Server

Pendant la mise à niveau d’une instance SQL Server hébergeant un groupe de disponibilité Always On vers une nouvelle version de SQL Server, un nouveau Service Pack SQL Server ou une mise à jour cumulative, ou pendant l’installation d’un nouveau Service Pack ou d’une nouvelle mise à jour cumulative Windows, vous pouvez réduire le temps d’arrêt du réplica principal à un seul basculement manuel en effectuant une mise à niveau propagée (ou deux basculements manuels en cas de restauration automatique vers l’instance principale d’origine).

Pendant le processus de mise à niveau, un réplica secondaire ne sera pas disponible pour le basculement ou pour les opérations en lecture seule, et après la mise à niveau, il peut falloir un certain temps pour que le réplica secondaire rattrape le réplica principal en fonction du volume d’activité sur le réplica principal (par conséquent, attendez-vous à un trafic réseau élevé).

Sachez également qu’après le basculement initial vers un réplica secondaire exécutant une version plus récente de SQL Server, les bases de données de ce groupe de disponibilité s’exécuteront via un processus de mise à niveau vers la version la plus récente. Pendant ce temps, aucun réplica lisible ne sera présent pour aucune de ces bases de données. Le temps d’arrêt après le basculement initial dépend du nombre de bases de données dans le groupe de disponibilité. Si vous prévoyez une restauration automatique sur le réplica principal d’origine, cette étape n’est pas répétée quand vous procédez à la restauration automatique.

Notes

Cet article ne concerne que la mise à niveau de SQL Server lui-même. Il ne couvre pas la mise à niveau du système d’exploitation contenant le cluster de basculement Windows Server (WSFC). La mise à niveau du système d’exploitation Windows hébergeant le cluster de basculement n’est pas prise en charge pour les systèmes d’exploitation avant Windows Server 2012 R2. Pour mettre à niveau un nœud de cluster s’exécutant sur Windows Server 2012 R2, consultez la rubrique Cluster Operating System Rolling Upgrade (Mise à niveau propagée du système d’exploitation de cluster).

Prérequis

Avant de commencer, passez en revue les informations importantes suivantes :

• Mises à niveau des éditions et versions prises en charge : vérifiez que vous pouvez effectuer une mise à niveau vers la dernière version de SQL Server depuis votre version du système d’exploitation Windows et votre version de SQL Server. Par exemple, si vous effectuez une mise à niveau directement à partir d’une instance SQL Server 2005, votre niveau de compatibilité de base de données est mis à niveau.

• Choisir une méthode de mise à niveau du moteur de base de données : pour effectuer la mise à niveau dans l’ordre correct, sélectionnez la méthode et les étapes de mise à niveau appropriées après avoir passé en revue les mises à niveau des éditions et versions prises en charge, en fonction des autres composants installés dans votre environnement.

• Planifiez et testez le plan de mise à niveau du moteur de base de données : passez en revue les notes de publication et les problèmes de mise à niveau connus, la liste de contrôle de prégradation et développez et testez le plan de mise à niveau.

• Exigences matérielle et logicielle pour l’installation de SQL Server : passez en revue les exigences logicielles pour l’installation de SQL Server. Si des logiciels supplémentaires sont nécessaires, installez-les sur chaque nœud avant de commencer le processus de mise à niveau pour réduire les éventuels temps d’arrêt.

• Vérifiez si la capture des changements de données ou la réplication est utilisée pour des bases de données de groupe de disponibilité : si une base de données dans le groupe de disponibilité est activée pour la capture des changements de données (CDC), suivez ces instructions.

Notes

• Le mélange de versions d’instances SQL Server dans le même groupe de disponibilité n’est pas pris en charge en dehors d’une mise à niveau propagée et ne doit pas exister dans cet état pendant des périodes prolongées, car la mise à niveau doit être effectuée rapidement. L’autre option de mise à niveau de SQL Server 2016 (13.x) et versions ultérieures consiste à utiliser un groupe de disponibilité distribué.
• L’utilisation de la fonctionnalité Windows Cluster-Aware Update (CAU) pour mettre à jour les groupes de disponibilité Always On n’est pas prise en charge.

Concepts de base de la mise à niveau propagée pour les groupes de disponibilité

Consultez les instructions suivantes pour effectuer la mise à niveau/mise à jour du serveur afin de réduire le temps d’arrêt et la perte de données de vos groupes de disponibilité :

• Avant de commencer la mise à niveau propagée :

  • Effectuez un basculement manuel pratique sur au moins l’une de vos instances de réplica de validation synchrone.

  • Protégez vos données en effectuant une sauvegarde complète de base de données sur chaque base de données de disponibilité.

  • Exécutez DBCC CHECKDB sur chaque base de données de disponibilité.

• Procédez toujours d’abord à la mise à niveau des instances du réplica secondaire distant, puis des instances du réplica secondaire local et enfin de l’instance du réplica principal.

• Les sauvegardes ne peuvent pas être exécutées dans une base de données qui est en cours de mise à niveau. Avant de mettre les réplicas secondaires à niveau, configurez la préférence de sauvegarde automatisée pour exécuter les sauvegardes uniquement sur le réplica principal. Pendant une mise à niveau de version, aucun réplica n’est lisible ou disponible pour les sauvegardes. Lors d’une mise à niveau sans version, vous pouvez configurer des sauvegardes automatisées pour qu’elles s’exécutent sur des réplicas secondaires avant de mettre à niveau le réplica principal.

• Pendant une mise à niveau de version, les instances de réplica secondaire accessibles en écriture ne peuvent pas être lues après une mise à niveau d’un réplica secondaire et avant que le réplica principal ne soit basculé vers un réplica secondaire mis à niveau ou que le réplica principal ne soit mis à niveau.

• Pour éviter les basculements involontaires des groupes de disponibilité pendant le processus de mise à niveau, supprimez le basculement des groupes de disponibilité dans tous les réplicas avec validation synchrone avant de commencer.

• Ne mettez à pas à niveau l’instance du réplica principal avant de basculer le groupe de disponibilité sur une instance mise à niveau qui a un réplica secondaire. Sinon, les applications clientes peuvent subir un temps d’arrêt prolongé pendant la mise à niveau sur l’instance de réplica principal.

• Basculez toujours le groupe de disponibilité sur une instance de réplica secondaire avec validation synchrone. Si vous basculez le groupe de disponibilité sur une instance de réplica secondaire en validation asynchrone, les bases de données sont exposées à une perte de données, et le déplacement des données est automatiquement suspendu jusqu’à ce que vous le repreniez manuellement.

• Ne procédez pas à la mise à niveau de l’instance de réplica principal avant la mise à niveau ou à jour des instances nœuds de réplica secondaire. Un réplica principal mis à niveau n’envoie plus les journaux à un réplica secondaire dont l’instance SQL Server n’a pas encore été mise à niveau à la même version. Lorsque le déplacement des données vers un réplica secondaire est suspendu, aucun basculement automatique ne se produit pour ce réplica, et vos bases de données de disponibilité sont vulnérables à une perte de données. Cela s’applique également lors d’une mise à niveau propagée où vous basculez manuellement d’un ancien serveur principal vers un nouveau serveur principal. Par conséquent, après avoir mis à niveau l’ancien principal, vous devrez peut-être reprendre la synchronisation.

• Avant de basculer un groupe de disponibilité, vérifiez que l’état de synchronisation de la cible de basculement est SYNCHRONIZED.

  Avertissement

  L’installation d’une nouvelle instance ou d’une nouvelle version de SQL Server sur un serveur doté d’une version antérieure de SQL Server peut entraîner par inadvertance une panne pour tout groupe de disponibilité hébergé par l’ancienne version de SQL Server. Cela est dû au fait que pendant l’installation de l’instance ou de la version de SQL Server, le module de haute disponibilité SQL Server (RHS.EXE) est mis à niveau. Cela occasionne une interruption temporaire de vos groupes de disponibilité existants dans le rôle principal du serveur. Par conséquent, nous vous recommandons vivement d’effectuer l’une des opérations suivantes lors de l’installation d’une version plus récente de SQL Server sur un système hébergeant déjà une version antérieure de SQL Server avec un groupe de disponibilité :

  • Installer la nouvelle version de SQL Server dans le cadre d’une fenêtre de maintenance.

  • Basculez le groupe de disponibilité vers le réplica secondaire afin qu’il ne soit pas principal pendant l’installation de la nouvelle instance SQL Server.

Processus de mise à niveau propagée

Dans la pratique, le processus exact dépend de facteurs comme la topologie de déploiement de vos groupes de disponibilité et du mode de validation de chaque réplica. Toutefois, dans le scénario le plus simple, une mise à niveau propagée est un processus en plusieurs étapes qui, dans sa forme la plus simple, implique les étapes suivantes :

1. Supprimer le basculement automatique sur tous les réplicas avec validation synchrone
2. Mettre à niveau toutes les instances de réplica secondaire avec validation asynchrone.
3. Mettre à niveau toutes les instances de réplica secondaire distant avec validation synchrone.
4. Mettre à niveau toutes les instances de réplica secondaire local avec validation synchrone.
5. Basculer manuellement le groupe de disponibilité (qui vient d’être mis à niveau) sur un réplica secondaire local avec validation synchrone.
6. Mettre à niveau ou mettre à jour l’instance de réplica local qui hébergeait précédemment le réplica principal.
7. Configurer le basculement automatique des partenaires de basculement selon les besoins.

Si nécessaire, effectuez un basculement manuel supplémentaire pour rétablir la configuration d’origine du groupe de disponibilité.

La mise à niveau d’un réplica de validation synchrone et sa mise hors connexion ne retardera pas les transactions sur le serveur principal. Une fois que le réplica secondaire est déconnecté, les transactions sont validées sur le réplica principal sans attendre les journaux pour renforcer la sécurité sur le réplica secondaire. S'il REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT est défini sur soit 1 soit 2, le réplica principal peut être indisponible pour les lectures/écritures lorsqu'un nombre correspondant de réplicas secondaires de synchronisation ne sont pas disponibles pendant le processus de mise à jour.

Quand vous effectuez une mise à niveau sur place d’un réplica secondaire vers une version plus récente de SQL Server, la base de données dans le groupe de disponibilité reste à l’état Synchronisation/En récupération ou Synchronisé/En récupération jusqu’à ce que le groupe de disponibilité soit basculé manuellement, ce qui termine la récupération et met à niveau la base de données. Un réplica principal mis à niveau ne peut plus expédier les journaux vers un réplica secondaire de version inférieure et les arrêts de déplacement des données, aucun basculement automatique ne peut se produire pour ce réplica, et vos bases de données de disponibilité sont vulnérables à la perte de données. Après avoir mis à niveau l'ancienne source principale, vous devrez peut-être reprendre la synchronisation. Nous vous recommandons de mettre à niveau tous les réplicas secondaires avant de basculer vers un réplica avec la nouvelle version. De cette façon, vous avez la possibilité d’effectuer un basculement après la mise à niveau de la ou des bases de données vers le nouveau format.

Groupe de disponibilité avec un réplica secondaire distant

Si vous avez déployé un groupe de disponibilité uniquement pour la récupération d’urgence, vous devrez peut-être basculer le groupe de disponibilité vers un réplica secondaire configuré pour une validation asynchrone. La figure suivante illustre une telle configuration :

Dans ce cas, vous devez basculer le groupe de disponibilité sur le réplica secondaire avec validation asynchrone pendant la mise à niveau propagée. Pour éviter la perte de données, remplacez le mode de validation par validation synchrone et attendez que le réplica secondaire soit synchronisé avant de basculer le groupe de disponibilité. Par conséquent, le processus de mise à niveau propagée peut se présenter comme suit :

1. Mettez à niveau l’instance de réplica secondaire sur le site distant.
2. Remplacez le mode de validation par validation synchrone.
3. Attendez que l’état de synchronisation soit SYNCHRONIZED.
4. Basculez le groupe de disponibilité vers le réplica secondaire sur le site distant.
5. Mettez à niveau ou mettez à jour l’instance de réplica local (site principal).
6. Basculez le groupe de disponibilité sur le site principal.
7. Remplacez le mode de validation par validation asynchrone.

Étant donné que le mode de validation synchrone n’est pas un paramètre recommandé pour la synchronisation de données sur un site distant, les applications clientes peuvent remarquer une augmentation immédiate de la latence de la base de données après la modification du paramètre. Par ailleurs, avec le basculement, tous les messages du journal sans accusé de réception sont ignorés. Le nombre de messages de journal ignorés peut être significatif en raison de la latence réseau élevée entre les deux sites, ce qui entraîne l’expérience d’un volume élevé de défaillance transactionnelle. Vous pouvez réduire l’impact sur les applications clientes en procédant comme suit :

• Sélectionnez soigneusement une fenêtre de maintenance pendant le trafic client faible.

• Lors de la mise à niveau ou de la mise à jour de SQL Server sur le site principal, revenez au mode de disponibilité en validation asynchrone, puis revenez à la validation synchrone lorsque vous êtes prêt à basculer à nouveau vers le site principal.

Groupe de disponibilité avec des nœuds d’instance de cluster de basculement

Si un groupe de disponibilité contient des nœuds d’instance de cluster de basculement, mettez à niveau les nœuds inactifs avant de mettre à niveau les nœuds actifs. La figure suivante illustre un scénario courant de groupe de disponibilité avec des instances de cluster de basculement pour une haute disponibilité locale et avec une validation asynchrone entre instances de cluster de basculement pour la récupération d’urgence, ainsi que la séquence de mise à niveau.

1. Mettre à niveau ou à jour REMOTE2
2. Basculer FCI2 sur REMOTE2
3. Mettre à niveau ou à jour REMOTE1
4. Mettre à niveau ou à jour PRIMARY2
5. Basculer FCI1 sur PRIMARY2
6. Mettre à niveau ou à jour PRIMARY1

Mettre à niveau ou à jour des instances SQL Server avec plusieurs groupes de disponibilité

Si vous exécutez plusieurs groupes de disponibilité avec des réplicas principaux sur des nœuds serveur distincts (une configuration active/active), le chemin de mise à niveau implique davantage d'étapes de basculement afin de maintenir la haute disponibilité pendant le processus. Supposons que vous exécutez trois groupes de disponibilité sur trois nœuds serveur avec toutes les répliques en mode de validation synchrone, comme indiqué dans le tableau suivant :

Groupe de disponibilité	Nœud1	Nœud2	Node3
AG1	Principal
AG2		Principal
AG3			Principal

Il peut être approprié dans votre situation d’effectuer une mise à niveau progressive équilibrée en charge dans la séquence suivante :

1. Basculer AG2 sur Node3 (pour libérer Node2)
2. Mettre à niveau ou à jour Node2
3. Basculer AG1 sur Node2 (pour libérer Node1)
4. Mettre à niveau ou à jour Node1
5. Basculer AG2 et AG3 sur Node1 (pour libérer Node3)
6. Mettre à niveau ou à jour Node3
7. Basculer AG3 sur Node3

Cette séquence de mise à niveau a un temps d’arrêt moyen de moins de deux basculements par groupe de disponibilité. La configuration obtenue est illustrée dans le tableau suivant.

Groupe de disponibilité	Nœud1	Nœud2	Node3
AG1		Principal
AG2	Principal
AG3			Principal

En fonction de votre implémentation spécifique, votre chemin de mise à niveau peut varier et le temps d’arrêt que les applications clientes peuvent également rencontrer.

Notes

Dans de nombreux cas, une fois la mise à niveau continue terminée, vous revenez au réplica principal d’origine.

Mise à niveau propagée d’un groupe de disponibilité distribué

Pour effectuer une mise à niveau propagée d’un groupe de disponibilité distribué, commencez par mettre à niveau tous les réplicas secondaires. Ensuite, basculez le redirecteur et mettez à niveau la dernière instance restante du deuxième groupe de disponibilité. Une fois que tous les autres réplicas ont été mis à niveau, basculez le principal global et mettez à niveau la dernière instance restante du premier groupe de disponibilité. Un diagramme détaillé avec des étapes est fourni dans une section ultérieure.

En fonction de votre implémentation spécifique, votre chemin de mise à niveau peut varier et le temps d’arrêt que les applications clientes peuvent également rencontrer.

Notes

Dans de nombreux cas, une fois la mise à niveau progressive terminée, vous revenez aux réplicas principaux d'origine.

Étapes générales pour mettre à niveau un groupe de disponibilité distribué

1. Sauvegardez toutes les bases de données, y compris les bases de données système et celles qui participent au groupe de disponibilité.
2. Mettez à niveau et redémarrez tous les réplicas secondaires du deuxième groupe de disponibilité (aval).
3. Mettez à niveau et redémarrez tous les réplicas secondaires du premier groupe de disponibilité (amont).
4. Basculez le réplica principal redirecteur vers un réplica secondaire mis à niveau du groupe de disponibilité secondaire.
5. Attendez la synchronisation des données. Les bases de données doivent apparaître synchronisées sur tous les réplicas en validation synchrone, tandis que le réplica principal global doit être synchronisé avec le redirecteur.
6. Mettez à niveau et redémarrez la dernière instance restante du groupe de disponibilité secondaire.
7. Basculez le réplica principal global vers un réplica secondaire mis à niveau du premier groupe de disponibilité.
8. Mettez à niveau la dernière instance restante du groupe de disponibilité principal.
9. Redémarrez le serveur qui vient d’être mis à niveau.
10. (facultatif) Rebasculez les deux groupes de disponibilité vers leurs réplicas principaux d’origine.

Important

Vérifiez la synchronisation entre chaque étape. Avant de passer à l’étape suivante, vérifiez que vos réplicas en validation synchrone sont synchronisés dans le groupe de disponibilité, et que votre réplica principal global est synchronisé avec le redirecteur dans le groupe de disponibilité distribué.

Recommandation : chaque fois que vous vérifiez la synchronisation, actualisez le nœud de base de données et le nœud de groupe de disponibilité distribué dans SQL Server Management Studio. Une fois que tout est synchronisé, enregistrez une capture d’écran de l’état de chaque réplica. Cela vous aide à suivre l’étape sur laquelle vous vous trouvez, fournit des preuves que tout fonctionnait correctement avant l’étape suivante et vous aide à résoudre les problèmes en cas de problème.

Exemple de diagramme d’une mise à niveau propagée d’un groupe de disponibilité distribué

Groupe de disponibilité	Réplica principal	Réplica secondaire
AG1	NODE1\SQLAG	NODE2\SQLAG
AG2	NODE3\SQLAG	NODE4\SQLAG
Groupe de disponibilité distribué	GD1 (global)	GD2 (redirecteur)

Voici les étapes pour mettre à niveau les instances de ce diagramme :

1. Sauvegardez toutes les bases de données, notamment les bases de données système et celles qui font partie du groupe de disponibilité.
2. Mettez à niveau NODE4\SQLAG (secondaire de AG2) et redémarrez le serveur.
3. Mettez à niveau NODE2\SQLAG (secondaire de AG1) et redémarrez le serveur.
4. Basculez AG2 de NODE3\SQLAG sur NODE4\SQLAG.
5. Mettez à niveau NODE3\SQLAG et redémarrez le serveur.
6. Basculez AG1 de NODE1\SQLAG sur NODE2\SQLAG.
7. Mettez à niveau NODE1\SQLAG et redémarrez le serveur.
8. (facultatif) Restaurez les réplicas principaux d’origine.
   1. Rebasculez AG2 de NODE4\SQLAG sur NODE3\SQLAG.
   2. Rebasculez AG1 de NODE2\SQLAG sur NODE1\SQLAG.

Si un troisième réplica existait dans chaque groupe de disponibilité, vous le mettez à niveau avant NODE3\SQLAG et NODE1\SQLAG.

Important

Vérifiez la synchronisation entre chaque étape. Avant de passer à l’étape suivante, vérifiez que vos réplicas en validation synchrone sont synchronisés dans le groupe de disponibilité, et que votre réplica principal global est synchronisé avec le redirecteur dans le groupe de disponibilité distribué.

Recommandation : chaque fois que vous vérifiez la synchronisation, actualisez à la fois le nœud de la base de données et le nœud du groupe de disponibilité distribué dans SQL Server Management Studio. Une fois que tout est synchronisé, prenez une capture d’écran et enregistrez-le. Cela vous aide à suivre l’étape sur laquelle vous vous trouvez, fournit des preuves que tout fonctionnait correctement avant l’étape suivante et vous aide à résoudre les problèmes en cas de problème.

Étapes spéciales pour la capture de données modifiées ou la réplication

Selon la mise à jour appliquée, des étapes supplémentaires peuvent être nécessaires pour les réplicas AG activés pour la capture de données modifiées ou la réplication. Consultez les notes de publication de la mise à jour pour déterminer si les étapes suivantes sont nécessaires :

1. Mettez à niveau chaque réplica secondaire.

2. Une fois tous les réplicas secondaires mis à niveau, basculez le groupe de disponibilité sur une instance mise à niveau.

3. Exécutez l’instruction Transact-SQL suivante sur l’instance qui héberge le réplica principal :

   EXECUTE [master].[sys].[sp_vupgrade_replication];
   

   Notes

   Cette commande peut prendre plusieurs minutes. Ignorez cette étape si vous utilisez SQL Server 2019 CU1 ou version ultérieure. Pour en savoir plus, consultez KB4530283.

4. Mettez à niveau l’instance qui était le réplica principal à l’origine.

Pour obtenir des informations générales, consultez la fonctionnalité CDC pourrait s'interrompre après la mise à niveau vers la dernière CU.

Contenu connexe

• Effectuer une mise à niveau de SQL Server à l’aide de l’Assistant Installation (Installation)
• Installer et configurer SQL Server sur Windows à partir de l’invite de commandes