Mise à niveau d’instances de réplica d’un groupe de disponibilité Always OnUpgrading Always On Availability Group Replica Instances

Cette rubrique s’applique à : OuiSQL Serveraucunbase de données SQL AzureaucunAzure SQL Data Warehouse aucun Parallel Data WarehouseTHIS TOPIC APPLIES TO: yesSQL ServernoAzure SQL DatabasenoAzure SQL Data Warehouse noParallel Data Warehouse

Pendant la mise à niveau d’une instance SQL ServerSQL Server hébergeant un groupe de disponibilité Always On vers une nouvelle version SQL Server 2017SQL Server 2017, un nouveau Service Pack SQL ServerSQL 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).When upgrading a SQL ServerSQL Server instance that hosts an Always On Availability Group (AG) to a new SQL Server 2017SQL Server 2017 version, to a new SQL ServerSQL Server service pack or cumulative update, or when installing to a new Windows service pack or cumulative update, you can reduce downtime for the primary replica to only a single manual failover by performing a rolling upgrade (or two manual failovers if failing back to the original primary). Pendant le processus de mise à niveau, un réplica secondaire n’est pas disponible pour le basculement ou pour des opérations en lecture seule et, après la mise à niveau, le réplica secondaire peut prendre un certain temps pour rattraper son retard par rapport au nœud de réplica principal en fonction du volume d’activité sur ce dernier (attendez-vous à un trafic réseau important).During the upgrade process, a secondary replica will not be available for failover or for read-only operations, and after the upgrade, it may take some time for the secondary replica to catch up with the primary replica node depending upon the volume of activity on the primary replica node (so expect high network traffic).

Note

Cet article ne concerne que la mise à niveau de SQL Server lui-même.This article limits the discussion to the upgrade of SQL Server itself. Il ne couvre pas la mise à niveau du système d’exploitation contenant le cluster de basculement Windows Server (WSFC).It does not cover upgrading the operating system containing the Windows Server Failover Cluster (WSFC). La mise à niveau du système d’exploitation Windows qui héberge le cluster de basculement n’est pas prise en charge psr les systèmes d’exploitation antérieurs à Windows Server 2012 R2.Upgrading the Windows operating system hosting the failover cluster is not supported for operating systems before 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).To upgrade a cluster node running on Windows Server 2012 R2, see Cluster Operating System Rolling Upgrade

PrerequisitesPrerequisites

Avant de commencer, passez en revue les informations importantes suivantes :Before you begin, review the following important information:

Note

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 qui met à niveau les réplicas en place.Mixing versions of SQL Server instances in the same AG is not supported outside of a rolling upgrade, which upgrades the replicas in place. Une version supérieure d’une instance SQL Server ne peut pas être ajoutée comme nouveau réplica à un groupe de disponibilité existant.A higher version of a SQL Server instance cannot be added as a new replica to an existing AG. Par exemple, un réplica SQL Server 2017 ne peut pas être ajouté à un groupe de disponibilité SQL Server 2016 existant.For example, a SQL Server 2017 replica cannot be added to an existing SQL Server 2016 AG. Pour migrer vers une nouvelle version d’une instance SQL Server à l’aide de groupes de disponibilité, la seule méthode prise en charge est d’utiliser un groupe de disponibilité distribué qui figure dans SQL Server 2016 Enterprise Edition ou version ultérieure.To migrate to a new version of the SQL Server instance using AGs, the only supported method is a distributed AG, which is in SQL Server 2016 Enterprise Edition or later.

Concepts de base de la mise à niveau propagée pour les groupes de disponibilité Always OnRolling Upgrade Basics for Always On AGs

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é :Observe the following guidelines when performing server upgrades or updates in order to minimize downtime and data loss for your AGs:

  • Avant de procéder à la mise à niveau propagée :Before starting the rolling upgrade,

    • Procédez à un essai de basculement manuel sur au moins l’une de vos instances de réplica avec validation synchrone.Perform a practice manual failover on at least one of your synchronous-commit replica instances

    • Protégez vos données en effectuant une sauvegarde complète de chaque base de données de disponibilité.Protect your data by performing a full database backup on every availability database

    • Exécutez la commande DBCC CHECKDB sur chaque base de données de disponibilité.Run DBCC CHECKDB on every availability database

  • 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.Always upgrade the remote secondary replica instances first, then local secondary replica instances next, and the primary replica instance last.

  • Les sauvegardes ne peuvent pas être exécutées dans une base de données qui est en cours de mise à niveau.Backups cannot occur on a database that is in the process of being upgraded. 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.Prior to upgrading the secondary replicas, configure the automated backup preference to run backups only on the primary replica. Pendant une mise à niveau de version, aucun réplica n’est lisible ou disponible pour les sauvegardes.During a version upgrade, no replicas are readable or available for backups. Pendant une mise à niveau sans version, vous pouvez configurer des sauvegardes automatisées s’exécutant sur des réplicas secondaires avant la mise à niveau du réplica principal.During a non-version upgrade, you can configure automated backups to run on secondary replicas prior to upgrading the primary replica.

  • 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.During a version upgrade, readable secondaries cannot be read after an upgrade of the readable secondary and before either the primary replica is failed over to an upgraded secondary or the primary replica is upgraded.

  • 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.To prevent the AG from unintended failovers during the upgrade process, remove availability failover from all synchronous-commit replicas before you begin.

  • 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.Do not upgrade the primary replica instance before failing over the AG to an upgraded instance with a secondary replica first. Sinon, les applications clientes risquent de connaître des temps morts prolongés lors de la mise à niveau sur l’instance de réplica principal.Otherwise, client applications may suffer extended downtime during the upgrade on the primary replica instance.

  • Basculez toujours le groupe de disponibilité sur une instance de réplica secondaire avec validation synchrone.Always fail over the AG to a synchronous-commit secondary replica instance. Si vous basculez le groupe de disponibilité sur une instance de réplica secondaire avec 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.If you fail over to an asynchronous-commit secondary replica instance, the databases is vulnerable to data loss, and data movement is automatically suspended until you manually resume data movement.

  • 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.Do not upgrade the primary replica instance before upgrading or updating any other secondary replica instance. Un réplica principal mis à niveau n'envoie plus les journaux à un réplica secondaire dont l’instance SQL Server 2017SQL Server 2017 n'a pas encore été mise à niveau à la même version.An upgraded primary replica can no longer ship logs to any secondary replica whose SQL Server 2017SQL Server 2017 instance that has not yet been upgraded to the same 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.When data movement to a secondary replica is suspended, no automatic failover can occur for that replica, and your availability databases are vulnerable to data loss.

  • Avant de basculer un groupe de disponibilité, vérifiez que l’état de synchronisation de la cible de basculement est SYNCHRONISÉ.Before failing over an AG, verify that the synchronization state of the failover target is SYNCHRONIZED.

Processus de mise à niveau propagéeRolling Upgrade Process

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.In practice, the exact process depends on factors such as the deployment topology of your AGs and the commit mode of each replica. Cependant, dans le scénario le plus simple, une mise à niveau propagée est un processus en plusieurs étapes impliquant les étapes suivantes :But in the simplest scenario, a rolling upgrade is a multi-stage process that in its simplest form involves the following steps:

Mise à niveau de groupe de disponibilité dans un scénario HADRAG Upgrade in HADR Scenario

  1. Supprimer le basculement automatique sur tous les réplicas avec validation synchroneRemove automatic failover on all synchronous-commit replicas

  2. Mettre à niveau toutes les instances de réplica secondaire distant exécutant les réplicas secondaires avec validation asynchroneUpgrade all remote secondary replica instances running asynchronous-commit secondary replicas

  3. Mettre à niveau instances de réplica secondaire local qui n'exécutent pas le réplica principalUpgrade the all local replica secondary instances that are not currently running the primary replica

  4. Basculer manuellement le groupe de disponibilité sur un réplica secondaire local avec validation synchroneManually fail over the AG to a local synchronous-commit secondary replica

  5. Mettre à niveau ou mettre à jour l'instance de réplica local qui hébergeait précédemment le réplica principalUpgrade or update the local replica instance that formerly hosted the primary replica

  6. Configurer le basculement automatique des partenaires de basculement selon les besoinsConfigure automatic failover partners as desired

    Si nécessaire, effectuez un basculement manuel supplémentaire pour rétablir la configuration d’origine du groupe de disponibilité.If necessary, you can perform an extra manual failover to return the AG to its original configuration.

Groupe de disponibilité avec un réplica secondaire distantAG with One Remote Secondary Replica

Si vous avez déployé un groupe de disponibilité uniquement pour la récupération d’urgence, vous devez peut-être le basculer sur un réplica secondaire avec validation asynchrone.If you have deployed an AG only for disaster recovery, you may need to fail over the AG to an asynchronous-commit secondary replica. Cette configuration est illustrée dans la figure ci-dessous :Such configuration is illustrated by the following figure:

Mise à niveau de groupe de disponibilité dans un scénario de récupération d’urgenceAG Upgrade in DR Scenario

Dans ce cas, vous devez basculer le groupe de disponibilité sur le réplica secondaire avec validation asynchrone pendant la mise à niveau propagée.In this situation, you must fail over the AG to the asynchronous-commit secondary replica during the rolling upgrade. Pour éviter la perte de données, changez le mode de validation en validation synchrone et attendez que le réplica secondaire soit synchronisé avant de basculer le groupe de disponibilité.To prevent data loss, change the commit mode to synchronous commit and wait for the secondary replica to be synchronized before you fail over the AG. Par conséquent, le processus de mise à niveau à jour peut ressembler à ce qui suit :Therefore, the rolling upgrade process may look as follows:

  1. Mise à niveau l’instance de réplica secondaire sur le site distantUpgrade the secondary replica instance on the remote site

  2. Changer le mode de validation en validation synchroneChange the commit mode to synchronous commit

  3. Patienter jusqu'à ce que l'état de synchronisation soit SYNCHRONIZEDWait until synchronization state is SYNCHRONIZED

  4. Basculer le groupe de disponibilité sur le réplica secondaire du site distantFail over the AG to the secondary replica on the remote site

  5. Mettre à niveau ou mettre à jour l’instance de réplica local (site principal)Upgrade or update the local (primary site) replica instance

  6. Rebasculer le groupe de disponibilité sur le site principalFail over the AG back to the primary site

  7. Changer le mode de validation en validation asynchroneChange the commit mode to asynchronous commit

    Le mode de validation synchrone n'étant pas recommandé pour la synchronisation des 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 modification du paramètre.Since the synchronous-commit mode is not a recommended setting for data synchronization to a remote site, client applications may notice an immediate increase in database latency after the setting change. Par ailleurs, avec le basculement, tous les messages du journal sans accusé de réception sont ignorés.Moreover, performing a failover causes all unacknowledged log messages to be discarded. Le nombre de messages de journal ignorés peut être important en raison de la latence réseau élevée entre les deux sites, à l’origine d’un grand nombre d’échecs de transactions des clients.The number discarded log messages can be significant due to the high network latency between the two sites, causing clients to experience a high volume of transactional failure. Pour réduire l’impact sur les applications clientes, effectuez les actions suivantes :You can minimize impact to client applications by doing the following actions:

  • Sélectionnez avec précaution une fenêtre de maintenance lorsque le trafic est faible sur le clientCarefully select a maintenance window during low client traffic

  • Lors de la mise à niveau ou mise à jour sur le site principal SQL Server 2017SQL Server 2017 , revenez au mode de disponibilité validation asynchrone, puis rétablissez la validation synchrone lorsque vous êtes prêt à effectuer le basculement sur le site principalWhile upgrading or updating SQL Server 2017SQL Server 2017 on the primary site, change the availability mode back to asynchronous commit, then revert to synchronous commit when you are ready to fail over to the primary site again

Groupe de disponibilité avec des nœuds d’instance de cluster de basculementAG with Failover Cluster Instance Nodes

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.If an AG contains failover cluster instance (FCI) nodes, you should upgrade the inactive nodes before you upgrade the active nodes. 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.The following figure illustrates a common AG scenario with FCIs for local high availability and asynchronous commit between the FCIs for remote disaster recovery, and the upgrade sequence.

Mise à niveau de groupe de disponibilité avec des instances de cluster de basculementAG Upgrade with FCIs

  1. Mettre à niveau ou à jour REMOTE2Upgrade or update REMOTE2

  2. Basculer FCI2 sur REMOTE2Fail over FCI2 to REMOTE2

  3. Mettre à niveau ou à jour REMOTE1Upgrade or update REMOTE1

  4. Mettre à niveau ou à jour PRIMARY2Upgrade or update PRIMARY2

  5. Basculer FCI1 sur PRIMARY2Fail over FCI1 to PRIMARY2

  6. Mettre à niveau ou à jour PRIMARY1Upgrade or update PRIMARY1

Mettre à niveau/mettre à jour des instances SQL Server avec plusieurs groupes de disponibilitéUpgrade Update SQL Server Instances with Multiple AGs

Si vous exécutez plusieurs groupes de disponibilité avec des réplicas principaux sur des nœuds de serveur distincts (configuration active/active), le chemin de mise à niveau implique des étapes de basculement supplémentaires pour assurer la haute disponibilité dans le processus.If you are running multiple AGs with primary replicas on separate server nodes (an Active/Active configuration), the upgrade path involves more failover steps to preserve high availability in the process. Supposons que vous exécutez trois groupes de disponibilité sur trois nœuds de serveur et que tous les réplicas s’exécutent en mode de validation synchrone, comme l’illustre le tableau suivant :Suppose you are running three AGs on three server nodes with all replicas in synchronous commit mode as shown in the following table:

Groupe de disponibilitéAG Nœud1Node1 Nœud2Node2 Node3Node3
AG1AG1 PrincipalPrimary
AG2AG2 PrincipalPrimary
AG3AG3 PrincipalPrimary

Il peut s'avérer nécessaire d'effectuer une mise à niveau/ propagée à charge équilibrée dans l'ordre suivant :It may be appropriate in your situation to perform a load-balanced rolling upgrade in the following sequence:

  1. Basculer AG2 sur Nœud3 (pour libérer Nœud2)Fail over AG2 to Node3 (to free up Node2)

  2. Mettre à niveau ou à jour Nœud2Upgrade or update Node2

  3. Basculer AG1 sur Nœud2 (pour libérer Nœud1)Fail over AG1 to Node2 (to free up Node1)

  4. Mettre à niveau ou à jour Nœud1Upgrade or update Node1

  5. Basculer AG2 et AG3 sur Nœud1 (pour libérer Nœud3)Fail over both AG2 and AG3 to Node1 (to free up Node3)

  6. Mettre à niveau ou à jour Nœud3Upgrade or update Node3

  7. Basculer AG3 sur Nœud3Fail over AG3 to Node3

    Cette séquence de mise à niveau a un temps d’arrêt moyen de moins de deux basculements par groupe de disponibilité.This upgrade sequence has an average downtime of fewer than two failovers per AG. La configuration obtenue est illustrée dans le tableau suivant.The resulting configuration is shown in the following table.

Groupe de disponibilitéAG Nœud1Node1 Nœud2Node2 Node3Node3
AG1AG1 PrincipalPrimary
AG2AG2 PrincipalPrimary
AG3AG3 PrincipalPrimary

Le chemin d'accès de la mise à niveau varie selon votre implémentation. Le temps mort que les applications clientes peuvent rencontrer varie également.Based on your specific implementation, your upgrade path may vary, and the downtime that client applications experience may vary as well.

Note

Dans de nombreux cas, une fois la mise à niveau propagée terminée, vous rebasculez sur le réplica principal d’origine.In many cases, after the rolling upgrade is completed, you will fail back to the original primary replica.

Étapes spéciales pour la capture de données modifiées ou la réplicationSpecial steps for change data capture or replication

En fonction de la mise à jour appliquée, des étapes supplémentaires peuvent être nécessaires pour les bases de données de réplica de groupe de disponibilité qui sont activées pour la réplication ou la capture de données modifiées.Depending on the update being applied, additional steps may be required for AG replica databases that are enabled for change data capture or replication. Consultez les notes de publication de la mise à jour pour déterminer si les étapes suivantes sont nécessaires :Refer to the release notes for the update to determine if the following steps are required:

  1. Mettez à niveau chaque réplica secondaire.Upgrade each secondary replica.

  2. Une fois tous les réplicas secondaires mis à niveau, basculez le groupe de disponibilité sur une instance mise à niveau.After all secondary replicas have been upgraded, fail over the AG to an upgraded instance.

  3. Exécutez l’instruction Transact-SQL suivante sur l’instance qui héberge le réplica principal :Run the following Transact-SQL on the instance that hosts the primary replica:

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

    Note

    L’exécution de cette commande peut durer plusieurs minutes.This command may take several minutes to run.

  4. Mettez à niveau l’instance qui était le réplica principal à l’origine.Upgrade the instance that was originally the primary replica.

Pour plus d’informations, consultez Les fonctionnalités de capture de données modifiées peuvent s’interrompre après la mise à niveau vers la dernière version CU.For background information, see CDC functionality may break after upgrading to the latest CU.

Voir aussiSee Also

Effectuer une mise à niveau vers SQL Server 2016 à l’aide de l’Assistant Installation (programme d’installation)Upgrade to SQL Server 2016 Using the Installation Wizard (Setup)

Installer SQL Server 2016 à partir de l’invite de commandesInstall SQL Server 2016 from the Command Prompt