Mettre à niveau ou corriger des bases de données répliquées
S’applique à :
SQL Server - Windows uniquement
SQL Server prend en charge la mise à niveau des bases de données répliquées à partir des versions précédentes de SQL Server ; il n’est pas nécessaire d’arrêter l’activité sur d’autres nœuds pendant la mise à niveau d’un nœud.
Prérequis
Prenez soin de respecter les règles relatives aux versions qui sont prises en charge dans une topologie :
Un serveur de distribution peut être n’importe quelle version tant qu’elle est supérieure ou égale à la version du serveur de publication (dans de nombreux cas, le serveur de distribution est la même instance que le serveur de publication).
Toute version convient pour le serveur de publication dès lors qu'elle est inférieure ou égale à celle du serveur de distribution.
La version de l’abonné dépend du type de publication :
La version d'un Abonné à une publication transactionnelle peut être n'importe laquelle des deux versions du serveur de publication. Par exemple : un éditeur SQL Server 2012 (11.x) peut avoir des abonnés SQL Server 2014 (12.x) et SQL Server 2016 (13.x), et un éditeur SQL Server 2016 (13.x) peut avoir des abonnés SQL Server 2014 (12.x) et SQL Server 2012 (11.x).
Un abonné à une publication de fusion peut avoir toute version égale ou inférieure à la version de l’éditeur qui est prise en charge selon le cycle de prise en charge du cycle de vie des versions.
Chemins de mise à niveau
Le chemin de mise à niveau vers SQL Server dépend du modèle de déploiement. SQL Server offre deux chemins de mise à niveau en général :
Côte à côte Déployez un environnement parallèle et déplacez les bases de données ainsi que les objets de niveau instance associés, tels que les connexions et les travaux, vers le nouvel environnement.
Mise à niveau sur place : Autorisez le support d’installation de SQL Server à mettre à niveau l’installation de SQL Server existante en remplaçant les bits de SQL Server et en mettant à niveau les objets de base de données. Pour les environnements utilisant des groupes de disponibilité (AG) ou des instances de cluster de basculement (FCI), une mise à niveau sur place est combinée avec une mise à niveau continue pour réduire les temps d’arrêt.
Une approche courante pour mettre à niveau les topologies de réplication côte à côte consiste à déplacer en parties des paires éditeur-abonné vers le nouvel environnement, plutôt qu'un déplacement de toute la topologie. Cette approche par phases permet de contrôler les temps d’arrêt et réduit l’impact dans une certaine mesure pour l’entreprise en fonction de la réplication.
La plupart de cet article est limité à la mise à niveau de la version de SQL Server. Toutefois, le processus de mise à niveau sur place doit également être appliqué lors de la mise à jour corrective de SQL Server avec un Service Pack ou une mise à jour cumulative.
Remarques
La mise à niveau d’une topologie de réplication est un processus en plusieurs étapes. Nous vous recommandons d’essayer une mise à niveau d’un réplica de votre topologie de réplication dans un environnement de test avant d’exécuter la mise à niveau sur l’environnement de production réel. Cela permet de mettre en place toute documentation opérationnelle requise pour la gestion de la mise à niveau sans entraîner de temps d’arrêt coûteux et longs pendant le processus de mise à niveau réel. Vous pouvez réduire considérablement les temps d’arrêt avec l’utilisation des groupes de disponibilité et/ou des instances de cluster de basculement pour leurs environnements de production lors de la mise à niveau de leur topologie de réplication. En outre, nous vous recommandons d’effectuer des sauvegardes de toutes les bases de données, notamment msdb, master, bases de données de distribution et bases de données utilisateur participant à la réplication avant d’essayer la mise à niveau.
Quand votre base de données de distribution est dans une instance de cluster de basculement, vérifiez que tous les nœuds participants utilisent la même build. Nous vous déconseillons d’effectuer une configuration dans laquelle un nœud est une version SQL Server antérieure à SQL Server 2016 (13.x) SP2-CU3 ou SQL Server 2017 (14.x) CU6 et l’autre nœud est une version SQL Server ultérieure à SQL Server 2016 (13.x) SP2-CU3 ou SQL Server 2017 (14.x) CU6. Depuis SQL Server 2016 (13.x) SP2-CU3 et SQL Server 2017 (14.x) CU6, la prise en charge a été ajoutée pour l'utilisation d'une base de données de distribution dans un groupe de disponibilité (AG) et pour les nouveaux objets (tables, procédures stockées) dans les bases de données de distribution. Si votre base de données de distribution se trouve dans une instance de cluster de basculement et que vous effectuez une migration par phases (et que vous ne pouvez mettre à niveau tous les nœuds vers la même version de SQL Server), pour réduire le temps de migration, nous vous recommandons d’effectuer des tâches de compte comme l’ajout d’un nouvel abonné, d’un abonnement, d’un serveur de publication ou d’une publication, sur le nœud qui a la dernière version de SQL Server.
Matrice de réplication
Matrice de compatibilité de la réplication transactionnelle et de capture instantanée
| Publisher | Serveur de distribution | Abonné |
|---|---|---|
| Azure SQL Managed InstanceAUTD | Azure SQL Managed InstanceAUTD | Azure SQL Database Azure SQL Managed InstanceAUTD Azure SQL Managed Instance2022 SQL Server 2022 (16.x) SQL Server 2019 (15.x) |
| Azure SQL Managed Instance2022 | Instance gérée Azure SQLAUTD Azure SQL Managed Instance2022 |
Azure SQL Database Azure SQL Managed InstanceAUTD Azure SQL Managed Instance2022 SQL Server 2022 (16.x) SQL Server 2019 (15.x) SQL Server 2017 (14.x) |
| SQL Server 2022 (16.x) | SQL Server 2022 (16.x) | Azure SQL Database Azure SQL Managed InstanceAUTD Azure SQL Managed Instance2022 SQL Server 2022 (16.x) SQL Server 2019 (15.x) SQL Server 2017 (14.x) |
| SQL Server 2019 (15.x) | SQL Server 2022 (16.x) SQL Server 2019 (15.x) |
Azure SQL Database Azure SQL Managed InstanceAUTD Azure SQL Managed Instance2022 SQL Server 2022 (16.x) SQL Server 2019 (15.x) SQL Server 2017 (14.x) SQL Server 2016 (13.x) |
| SQL Server 2017 (14.x) | SQL Server 2022 (16.x) SQL Server 2019 (15.x) SQL Server 2017 (14.x) |
Azure SQL Managed Instance2022 SQL Server 2022 (16.x) SQL Server 2019 (15.x) SQL Server 2017 (14.x) SQL Server 2016 (13.x) SQL Server 2014 (12.x) |
| SQL Server 2016 (13.x) | SQL Server 2022 (16.x) SQL Server 2019 (15.x) SQL Server 2017 (14.x) SQL Server 2016 (13.x) |
SQL Server 2019 (15.x) SQL Server 2017 (14.x) SQL Server 2016 (13.x) SQL Server 2014 (12.x) SQL Server 2012 (11.x) |
| SQL Server 2014 (12.x) | Azure SQL Managed InstanceAUTD Azure SQL Managed Instance2022 SQL Server 2022 (16.x) SQL Server 2019 (15.x) SQL Server 2017 (14.x) SQL Server 2016 (13.x) SQL Server 2014 (12.x) |
SQL Server 2017 (14.x) SQL Server 2016 (13.x) SQL Server 2014 (12.x) SQL Server 2012 (11.x) SQL Server 2008 R2 (10.50.x) SQL Server 2008 (10.0.x) |
| SQL Server 2012 (11.x) | SQL Server 2022 (16.x) SQL Server 2019 (15.x) SQL Server 2017 (14.x) SQL Server 2016 (13.x) SQL Server 2014 (12.x) SQL Server 2012 (11.x) |
SQL Server 2016 (13.x) SQL Server 2014 (12.x) SQL Server 2012 (11.x) SQL Server 2008 R2 (10.50.x) SQL Server 2008 (10.0.x) |
| SQL Server 2008 R2 (10.50.x) SQL Server 2008 (10.0.x) |
SQL Server 2022 (16.x) SQL Server 2019 (15.x) SQL Server 2017 (14.x) SQL Server 2016 (13.x) SQL Server 2014 (12.x) SQL Server 2012 (11.x) SQL Server 2008 R2 (10.50.x) SQL Server 2008 (10.0.x) |
SQL Server 2014 (12.x) SQL Server 2012 (11.x) SQL Server 2008 R2 (10.50.x) SQL Server 2008 (10.0.x) |
2022 s’applique à Azure SQL Managed Instance configurée avec la stratégie de mise à jour SQL Server 2022 . AUTD s’applique à Azure SQL Managed Instance configuré avec la stratégie de mise à jour Always-up-to-date (Mise à jour automatique).
Matrice de compatibilité de la réplication de fusion
| Publisher | Serveur de distribution | Abonné |
|---|---|---|
| SQL Server 2022 (16.x) | SQL Server 2022 (16.x) | SQL Server 2022 (16.x) SQL Server 2019 (15.x) SQL Server 2017 (14.x) SQL Server 2016 (13.x) SQL Server 2014 (12.x) SQL Server 2012 (11.x) SQL Server 2008 R2 (10.50.x) SQL Server 2008 (10.0.x) |
| SQL Server 2019 (15.x) | SQL Server 2022 (16.x) SQL Server 2019 (15.x) |
SQL Server 2019 (15.x) SQL Server 2017 (14.x) SQL Server 2016 (13.x) SQL Server 2014 (12.x) SQL Server 2012 (11.x) SQL Server 2008 R2 (10.50.x) SQL Server 2008 (10.0.x) |
| SQL Server 2017 (14.x) | SQL Server 2022 (16.x) SQL Server 2019 (15.x) SQL Server 2017 (14.x) |
SQL Server 2017 (14.x) SQL Server 2016 (13.x) SQL Server 2014 (12.x) SQL Server 2012 (11.x) SQL Server 2008 R2 (10.50.x) SQL Server 2008 (10.0.x) |
| SQL Server 2016 (13.x) | SQL Server 2022 (16.x) SQL Server 2019 (15.x) SQL Server 2017 (14.x) SQL Server 2016 (13.x) |
SQL Server 2016 (13.x) SQL Server 2014 (12.x) SQL Server 2012 (11.x) SQL Server 2008 R2 (10.50.x) SQL Server 2008 (10.0.x) |
| SQL Server 2014 (12.x) | SQL Server 2022 (16.x) SQL Server 2019 (15.x) SQL Server 2017 (14.x) SQL Server 2016 (13.x) SQL Server 2014 (12.x) |
SQL Server 2014 (12.x) SQL Server 2012 (11.x) SQL Server 2008 R2 (10.50.x) SQL Server 2008 (10.0.x) |
| SQL Server 2012 (11.x) | SQL Server 2022 (16.x) SQL Server 2019 (15.x) SQL Server 2017 (14.x) SQL Server 2016 (13.x) SQL Server 2014 (12.x) SQL Server 2012 (11.x) |
SQL Server 2012 (11.x) SQL Server 2008 R2 (10.50.x) SQL Server 2008 (10.0.x) |
| SQL Server 2008 R2 (10.50.x) SQL Server 2008 (10.0.x) |
SQL Server 2022 (16.x) SQL Server 2019 (15.x) SQL Server 2017 (14.x) SQL Server 2016 (13.x) SQL Server 2014 (12.x) SQL Server 2012 (11.x) SQL Server 2008 R2 (10.50.x) SQL Server 2008 (10.0.x) |
SQL Server 2008 R2 (10.50.x) SQL Server 2008 (10.0.x) |
Points importants relatifs à la mise à niveau
Exécuter l’agent de lecture du journal pour la réplication transactionnelle avant la mise à niveau
Avant de mettre à niveau SQL Server, assurez-vous que toutes les transactions validées des tables publiées ont bien été traitées par l’Agent de Lecture du Journal. Pour vous assurer que toutes les transactions sont traitées, procédez comme suit pour chaque base de données qui contient des publications transactionnelles :
Assurez-vous que l'Agent de lecture du journal s'exécute pour la base de données. Par défaut, cet agent s'exécute en permanence.
Arrêtez l'activité des utilisateurs sur les tables publiées.
Laissez à l'Agent de lecture du journal le temps de copier des transactions vers la base de données de distribution, puis arrêtez-le.
Exécutez sp_replcmds pour vérifier que toutes les transactions sont traitées. Le jeu de résultats de cette procédure doit être vide.
Exécutez sp_replflush pour fermer la connexion à partir de
sp_replcmdsMettez à niveau le serveur vers la dernière version de SQL Server.
Redémarrez SQL Server Agent et l’Agent de lecture du journal s’ils ne démarrent pas automatiquement après la mise à niveau.
Exécution des agents de réplication de fusion après la mise à niveau
Après la mise à niveau, exécutez l'Agent d'instantané pour chaque publication de fusion et l'Agent de fusion pour chaque abonnement afin de mettre à jour les métadonnées de réplication. Vous n’avez pas besoin d’appliquer la nouvelle capture instantanée, car il n’est pas nécessaire de réinitialiser les abonnements. Les métadonnées d'abonnement sont mises à jour lors de la première exécution de l'Agent de fusion après la mise à niveau. Ceci signifie que la base de données d'abonnement peut rester en ligne et active durant la mise à niveau du serveur de publication.
La réplication de fusion stocke les métadonnées de publication et d’abonnement dans plusieurs tables système des bases de données de publication et d’abonnement. L'Agent d'instantané met à jour les métadonnées de publication et l'Agent de fusion met à jour les métadonnées d'abonnement. Ce n’est nécessaire que pour générer un instantané de la publication. Si une publication de fusion utilise des filtres paramétrés, chaque partition a également un instantané. Il n’est pas nécessaire de mettre à jour ces instantanés partitionnés.
Exécutez les agents à partir de SQL Server Management Studio, du moniteur de réplication ou de la ligne de commande. Pour plus d’informations sur l’exécution de l’Agent d’instantané, consultez les articles suivants :
- Créer et appliquer l'instantané initial
- Démarrer et arrêter un Agent de réplication (SQL Server Management Studio)
- Créer et appliquer l'instantané initial
- Concepts des exécutables de l'agent de réplication
Pour plus d’informations sur l’exécution de l’Agent de fusion, consultez les articles suivants :
Après avoir mis à niveau SQL Server dans une topologie qui utilise la réplication de fusion, modifiez le niveau de compatibilité de toutes les publications si vous voulez utiliser les nouvelles fonctionnalités.
Mettre à niveau vers les éditions Standard, Workgroup ou Express
Avant de procéder à la mise à niveau d’une édition de SQL Server vers une autre, vérifiez que la fonctionnalité que vous utilisez actuellement est prise en charge dans l’édition vers laquelle vous effectuez la mise à niveau. Pour plus d’informations, consultez la section sur la réplication dans Éditions et fonctionnalités prises en charge de SQL Server 2022.
Étapes de la mise à niveau d’une topologie de réplication
Ces étapes décrivent l’ordre dans lequel les serveurs d’une topologie de réplication doivent être mis à niveau. Les mêmes étapes s’appliquent si vous exécutez une réplication transactionnelle ou de fusion. Toutefois, ces étapes ne couvrent pas la réplication entre pairs, les abonnements avec mise à jour en file d'attente, ni les abonnements avec mise à jour immédiate.
Mise à niveau sur place
- Mettez à niveau le distributeur.
- Mettez à niveau l’éditeur et l’abonné. Ces derniers peuvent être mis à niveau dans n’importe quel ordre.
Notes
Pour SQL Server 2008 (10.0.x) et SQL Server 2008 R2 (10.50.x), la mise à niveau du serveur de publication et de l’abonné doit être effectuée en même temps pour s’aligner sur la matrice de topologie de réplication. Les éditeurs ou abonnés SQL Server 2008 (10.0.x) et SQL Server 2008 R2 (10.50.x) ne peuvent pas avoir un éditeur ou abonné SQL Server 2016 (13.x) (ou supérieur). Si la mise à niveau en même temps n’est pas possible, utilisez une mise à niveau intermédiaire pour mettre à niveau les instances SQL Server vers SQL Server 2014 (12.x), puis mettez-les à niveau vers SQL Server 2016 (13.x) (ou version ultérieure).
Mise à niveau côte à côte
- Mettez à niveau le distributeur.
- Reconfigurez Configurer la distribution sur la nouvelle instance de SQL Server.
- Mettez à niveau l’éditeur.
- Mettez à niveau l’abonné.
- Reconfigurez toutes les paires éditeur/abonné, y compris la réinitialisation de l’abonné.
Étapes de migration côte à côte du serveur de distribution vers Windows Server
Une mise à niveau côte à côte est le seul chemin de mise à niveau disponible pour les instances de SQL Server qui participent à un cluster de basculement. Les étapes suivantes peuvent être effectuées sur une instance SQL Server autonome ou de cluster de basculement (FCI).
Configurez une nouvelle instance de SQL Server (indépendante ou FCI), une édition et une version comme votre distributeur sur Windows Server avec un nom de cluster Windows différent et soit un nom de FCI SQL Server, soit un nom d'hôte indépendant. Vous devez conserver la structure de répertoires identique à l’ancien serveur de distribution pour vous assurer que les exécutables des agents de réplication, les dossiers de réplication et les chemins des fichiers de base de données se trouvent au même chemin sur le nouvel environnement. Cela réduit toutes les étapes post-migration/mise à niveau requises.
Vérifiez que la réplication est synchronisée, puis arrêtez tous les agents de réplication.
Arrêtez l’instance du distributeur SQL Server actuelle. S’il s’agit d’une instance autonome, arrêtez le serveur. S’il s’agit d’une instance de cluster de basculement SQL Server, mettez l’intégralité du rôle SQL Server hors connexion dans le gestionnaire de cluster, y compris le nom du réseau.
Supprimez les entrées d’objet d’ordinateur DNS et Active Directory pour l’ancien environnement (instance de serveur de distribution actuelle).
Changez le nom d’hôte du nouveau serveur afin qu’il corresponde à celui de l’ancien serveur.
- S’il s’agit d’une instance de cluster de basculement (FCI) SQL Server, renommez la nouvelle FCI SQL Server avec le même nom de serveur virtuel que l’ancienne instance.
Copiez les fichiers de base de données à partir de l’instance précédente à l’aide d’une redirection SAN, d’une copie de stockage ou d’une copie de fichiers.
Mettez la nouvelle instance SQL Server en ligne.
Redémarrez tous les agents de réplication et vérifiez s’ils s’exécutent correctement.
Déterminez si la réplication fonctionne comme prévu.
Utilisez le support d’installation de SQL Server pour exécuter une mise à niveau sur place de votre instance SQL Server vers la nouvelle version de SQL Server.
Notes
Pour réduire les temps d’arrêt, nous vous recommandons d’effectuer la migration côte à côte du distributeur et la mise à niveau sur place vers SQL Server en tant qu’activités distinctes. Cela vous permet d’adopter une approche progressive, de réduire les risques et de réduire les temps d’arrêt.
Synchronisation Web pour la réplication de fusion
L’option de synchronisation Web pour la réplication de fusion nécessite de copier le SQL Server Replication Listener (replisapi.dll) sur le répertoire virtuel du serveur IIS utilisé pour la synchronisation. Lorsque vous configurez la synchronisation web, l’Assistant Configuration de la synchronisation web copie le fichier dans le répertoire virtuel. Si vous mettez à niveau les composants SQL Server installés sur le serveur IIS, vous devez manuellement copier replisapi.dll depuis le répertoire COM vers le répertoire virtuel sur le serveur IIS. Pour plus d’informations sur la synchronisation web, consultez Configuration de la synchronisation web.
Restaurer une base de données répliquée à partir d’une version antérieure
Pour vous assurer que les paramètres de réplication sont conservés lorsque vous restaurez la sauvegarde d'une base de données répliquée à partir d'une version précédente : effectuez la restauration vers un serveur et une base de données du même nom que le serveur et la base de données à l'origine de la sauvegarde.