Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
S'applique à :
SQL Server
Pour préserver votre solution de log shipping pour la récupération d’urgence, effectuez une mise à niveau ou appliquez des mises à jour de maintenance dans l’ordre approprié. Les mises à jour de maintenance incluent les Service Packs ou les mises à jour cumulatives.
Note
Une configuration de copie des journaux de transaction mise à niveau utilise l’option de configuration au backup compression default niveau du serveur pour contrôler si la compression de sauvegarde est utilisée pour les fichiers de sauvegarde du journal des transactions. Vous pouvez spécifier le comportement de compression des sauvegardes de journaux pour chaque configuration de l'expédition de journaux. Pour plus d’informations, consultez Configurer l'expédition de journaux (SQL Server).
Prerequisites
Avant de commencer, passez en revue les informations importantes suivantes.
| Article | Descriptif |
|---|---|
| Mises à niveau de version et d’édition prises en charge | Vérifiez que vous pouvez effectuer une mise à niveau vers votre version souhaitée de SQL Server à partir de votre système d’exploitation Windows existant et de la version de SQL Server. Par exemple, vous ne pouvez pas effectuer de mise à niveau directement à partir d’une instance SQL Server 2005 (9.x) vers SQL Server 2025 (17.x). |
| Choisir une méthode de mise à niveau du moteur de base de données | Sélectionnez la méthode de mise à niveau appropriée et les étapes en fonction de votre révision des mises à niveau de version et d’édition prises en charge. Considérez également les autres composants installés dans votre environnement pour mettre à niveau les composants dans l’ordre approprié. |
| Plan et test du 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 avant la mise à niveau et développez et testez le plan de mise à niveau. |
| Configuration matérielle et logicielle requise pour l’installation de SQL Server | Passez en revue la configuration logicielle requise pour l’installation de SQL Server. Si d’autres logiciels sont requis, installez-le sur chaque nœud avant de commencer le processus de mise à niveau pour réduire les temps d’arrêt. |
| Prise en charge du groupe de disponibilité autonome ajoutée dans SQL Server 2022 (16.x) | Si vous souhaitez commencer à utiliser des groupes de disponibilité autonomes avec la copie des journaux de transaction, vous devez supprimer et recréer la topologie de copie des journaux de transaction. Toutefois, si vous utilisez déjà des groupes de disponibilité contenus avec journalisation, les mises à niveau sont prises en charge. |
| Support TDS 8.0 ajouté dans SQL Server 2025 (17.x) | Si vous souhaitez utiliser TDS 8.0 avec l'expédition des journaux dans SQL 2025 et les versions ultérieures, vous devez d'abord supprimer votre configuration existante d'expédition des journaux. |
Protéger vos données avant la mise à niveau
Pour protéger vos données lors d’une mise à niveau de l’expédition des journaux de transaction, procédez comme suit :
Effectuez une sauvegarde complète de base de données sur chaque base de données primaire.
Pour plus d’informations, consultez Créer une sauvegarde complète de base de données (SQL Server).
Exécutez la commande DBCC CHECKDB sur chaque base de données primaire.
Important
Assurez-vous que votre serveur principal dispose d’un espace suffisant pour contenir les copies de sauvegarde des journaux pendant toute la durée de la mise à niveau des serveurs secondaires. Si vous basculez vers un secondaire, cette même préoccupation s'applique au secondaire (le nouveau primaire).
Mettre à niveau l’instance de serveur de surveillance (facultative)
Vous pouvez mettre à niveau l’instance de serveur de surveillance, si nécessaire. Toutefois, vous n’avez pas besoin de mettre à niveau le serveur moniteur facultatif lorsque vous mettez à niveau les serveurs principaux et secondaires.
Pendant la mise à niveau du serveur de surveillance, la configuration de l'expédition des journaux continue de fonctionner, mais son état n’est pas enregistré dans les tables du serveur de surveillance. Toutes les alertes configurées ne sont pas déclenchées pendant la mise à niveau du serveur moniteur. Après la mise à niveau, vous pouvez mettre à jour les informations dans les tables de suivi en exécutant la procédure stockée système sp_refresh_log_shipping_monitor. Pour plus d’informations sur un serveur de surveillance, consultez À propos de la copie des journaux (SQL Server).
Mettre à niveau les instances de serveur secondaire
Le processus de mise à niveau implique la mise à niveau des instances de serveur secondaire de SQL Server avant de mettre à niveau l’instance de serveur principal. Mettez toujours à niveau les instances SQL Server secondaires en premier. L'expédition de journaux continue tout au long du processus de mise à niveau, car les instances de serveur secondaire mises à niveau continuent de restaurer les sauvegardes de journaux à partir de l’instance de serveur principal.
Si vous mettez à niveau l’instance de serveur principal avant l’instance de serveur secondaire, la copie des journaux de transaction échoue, car une sauvegarde créée sur une version plus récente de SQL Server ne peut pas être restaurée sur une version antérieure de SQL Server. Vous pouvez mettre à niveau les instances secondaires simultanément ou en série, mais vous devez mettre à niveau toutes les instances secondaires avant de mettre à niveau l’instance principale pour éviter un échec de la journalisation des transactions.
Lors de la mise à niveau d’une instance de serveur secondaire, les travaux de copie et de restauration des journaux de transaction ne s’exécutent pas. Cette condition signifie que les sauvegardes du journal des transactions non bloquées s’accumulent sur le réplica principal et que vous devez disposer d’un espace suffisant pour contenir ces sauvegardes non bloquées. La quantité d’accumulation dépend de la fréquence de sauvegarde planifiée sur l’instance de serveur principal et de la séquence dans laquelle vous mettez à niveau les instances secondaires. En outre, si un serveur moniteur distinct est configuré, des alertes peuvent être déclenchées indiquant que les restaurations n’ont pas été effectuées depuis plus longtemps que l’intervalle configuré.
Une fois que vous avez mis à niveau les instances de serveurs secondaires, les travaux des agents de sauvegarde des journaux reprennent et continuent à copier et restaurer des sauvegardes de journaux à partir de l’instance de serveur principal vers les instances de serveurs secondaires. La durée nécessaire aux instances de serveur secondaire pour mettre à jour la base de données secondaire varie en fonction du temps nécessaire à la mise à niveau de l’instance de serveur secondaire et de la fréquence des sauvegardes sur le serveur principal.
Pendant la mise à niveau du serveur, la base de données secondaire elle-même n’est pas mise à niveau vers la nouvelle version. Elle est mise à niveau uniquement si elle est mise à niveau en ligne en lançant un basculement de la base de données fournie par le journal. En théorie, cette condition pourrait persister indéfiniment. La durée de la mise à niveau des métadonnées de la base de données lorsqu’un basculement est lancé est courte.
Important
L’option RESTORE WITH STANDBY n’est pas prise en charge pour une base de données qui nécessite une mise à niveau. Si une base de données secondaire mise à niveau est configurée à l’aide de l’utilisation RESTORE WITH STANDBY, les journaux des transactions ne peuvent plus être restaurés après la mise à niveau. Pour reprendre le log shipping sur cette base de données secondaire, vous devez reconfigurer le log shipping sur ce serveur de secours. Pour plus d’informations sur l’optionSTANDBY, consultez Restaurer une sauvegarde du journal des transactions (SQL Server).
Mettre à niveau l’instance de serveur principal
Étant donné que l'expédition des journaux est principalement une solution de récupération d’urgence, le scénario le plus simple et le plus courant consiste à mettre à niveau l’instance principale sur site. La base de données n’est pas disponible pendant cette mise à niveau. Une fois le serveur mis à niveau, la base de données est automatiquement remise en ligne, ce qui entraîne sa mise à niveau. Une fois la base de données mise à niveau, les travaux de copie des journaux de transaction reprendnt.
La fonction d'expédition des journaux prend également en charge la possibilité de basculer vers un serveur secondaire d'expédition des journaux et de modifier éventuellement les rôles entre les serveurs principaux et secondaires d'expédition des journaux.
Toutefois, étant donné que la copie des journaux de transaction n'est plus souvent configurée comme solution de haute disponibilité (des options plus récentes sont beaucoup plus robustes), le basculement ne réduit généralement pas la durée des interruptions. Les objets de base de données système ne sont pas synchronisés, ce qui peut rendre difficile pour les clients de localiser et se connecter à une base de données secondaire promue.