Remarques relatives à la migration

Sauvegarde / restauration SQL Server native

Les bases de données Microsoft SQL Server prennent en charge les opérations de sauvegarde et de restauration natives qui utilisent des fichiers de sauvegarde intégrale et différentielle (.bak) ou des restaurations de restauration différentielle et de consignation. L'utilisation de fichiers .bak natifs est le moyen le plus simple de sauvegarder et de restaurer des bases de données SQL Server et une méthode de migration simple pour une ou plusieurs bases de données dans une instance. Les sauvegardes intégrales de la base de données sur votre serveur existant sont effectuées et copiées dans un compartiment IBM Cloud Object Storage . Il est ensuite restauré, via un serveur de transfert avec s3fs ou rclone et partage SMB\Samba , sur votre serveur virtuel d'instance de base de données SQL Server dans IBM Cloud VPC.

Réplication transactionnelle

La réplication transactionnelle permet de transférer des modifications entre une base de données et une autre. Ces modifications peuvent inclure des données, des tables, des procédures mémorisées, des vues, etc. L'architecture comprend les éléments suivants:

• Diffuseur de publications-la base de données principale qui publie les données.
• Abonné: base de données secondaire qui reçoit les données répliquées.
• Distributeur: serveur qui stocke les métadonnées et les transactions pour la réplication transactionnelle et qui est idéalement un serveur distinct pour le diffuseur de publications ou l'abonné.

Le processus fonctionne comme suit:

• La réplication transactionnelle crée un instantané des objets et des données dans la base de données de publication et l'envoie à la base de données d'abonné. L'image instantanée est appliquée à la base de données de l'abonné.
• Les modifications de données et les modifications de schéma apportées au diffuseur de publications sont envoyées à l'abonné dans l'ordre dans lequel elles se sont produites et appliquées à l'abonné dans le même ordre.
• Lorsque les deux bases de données sont synchronisées et dans une fenêtre de maintenance:
  • Arrêtez tout accès au diffuseur de publications.
  • Vérifiez que la réplication est terminée.
  • Supprimez l'abonnement.
  • Activez l'accès à ce qui était l'abonné.
  • Mettez hors service ce qui était l'éditeur.

Pour plus d'informations, voir Réplication transactionnelle .

Mise en miroir de la base de données

La mise en miroir de la base de données a été dépréciée dans SQL Server 2012, mais elle est toujours référencée dans la documentation SQL 2019. Pour plus d'informations, voir Database mirroring in SQL Server. Il est discuté ici pour l'exhaustivité des méthodes de migration, cependant, recherchez soigneusement cette approche si vous voulez l'utiliser dans votre migration.

La mise en miroir de base de données dans SQL Server vous permet de conserver une copie, ou miroir, d'une base de données SQL Server sur un serveur de secours. La mise en miroir garantit que deux copies distinctes des données existent toujours. Par rapport à la transmission des journaux, la mise en miroir de la base de données est un peu plus compliquée à configurer, et elle comporte plus de restrictions. La mise en miroir de la base de données est plus facile à configurer si les deux serveurs du partenariat se trouvent dans le même domaine Windows, mais si ce n'est pas le cas, vous pouvez utiliser des certificats pour l'authentification de votre noeud final. Les étapes de base de la migration sont les suivantes:

• Configurez la mise en miroir de la base de données.
• Au moment de la coupure requise, arrêtez les applications qui utilisent les bases de données principales sur le serveur principal.
• Vérifiez que chaque base de données est à l'état synchronisé.
• Basculement sur chaque base de données utilisateur protégée par disque miroir.
• Supprimez le partenariat de mise en miroir.
• Redirigez les applications vers le nouveau serveur de base de données.
• Mettez hors service le serveur d'origine.

Transmission des journaux

La transmission des journaux SQL Server peut être configurée au niveau de la base de données et, au cours d'une période donnée, la sauvegarde du journal des transactions SQL Server sera effectuée et copiée sur le serveur de destination et restaurée. Les journaux de transactions contiennent un journal de toutes les transactions qui se produisent dans une base de données SQL Server . L'instance SQL Server à partir de laquelle la sauvegarde du journal des transactions est expédiée est appelée l'instance principale et l'instance SQL Server vers laquelle la sauvegarde du journal des transactions est expédiée est appelée l'instance secondaire. Avant de configurer la transmission des journaux, la base de données doit être en mode de récupération complète ou en mode de consignation en bloc.

Les paramètres de sauvegarde du journal des transactions SQL Server permettent l'adressage à un chemin réseau et le planificateur de travaux de sauvegarde peut être défini pour exécuter un travail de sauvegarde. Par défaut, le paramètre consiste à exécuter un travail de sauvegarde toutes les 15 minutes. Une fois la sauvegarde de la base de données planifiée, elle crée une sauvegarde intégrale de la base de données qui devra être récupérée sur le serveur secondaire. Pendant les heures de maintenance, un basculement du serveur principal vers le serveur secondaire peut être effectué, la transmission des journaux désactivée et le serveur principal mis hors service.

Toujours sur les groupes de disponibilité

SQL Server Les groupes de disponibilité Always On fournissent des solutions de haute disponibilité et de reprise après incident et sont disponibles dans les versions de SQL Server 2012 et ultérieures. Cette fonction peut être utilisée pour migrer vos bases de données SQL Server existantes vers IBM Cloud avec un temps d'indisponibilité minimal. Si vous disposez d'un cluster de basculement Windows Server existant avec des groupes de disponibilité Always On, vous pouvez étendre temporairement le cluster lors de la migration en créant une réplique secondaire supplémentaire avec réplication asynchrone. Au cours d'une fenêtre de maintenance, un basculement manuel peut être effectué pour activer le basculement.

Toujours sur les groupes de disponibilité répartis

Un groupe de disponibilité SQL Server Always On réparti s'étend sur deux groupes de disponibilité distincts. Chaque groupe de disponibilité est configuré sur deux clusters de basculement Windows Server (WSFC) différents, l'un à l'emplacement source et l'autre dans IBM Cloud VPC. Les systèmes d'exploitation et les versions SQL Server n'ont pas besoin d'être de la même version, à condition qu'ils puissent prendre en charge WSFC et les groupes de disponibilité. Cette méthode de migration est adaptée pour réhéberger les bases de données SQL Server indispensables à la mission. L'architecture de groupe de disponibilité distribué est une méthode de transfert de données efficace car la réplique principale transfère les données uniquement à la réplique du réexpéditeur dans IBM Cloud, puis le réexpéditeur est responsable de la synchronisation des données avec les répliques secondaires dans IBM Cloud. Une architecture typique est la suivante:

• Le cluster WSFC source héberge un groupe de disponibilité Always On, possède deux noeuds et utilise la réplication synchrone, avec reprise en ligne automatique.
• Le cluster WSFC cible, hébergé dans IBM Cloud dispose d'un groupe de disponibilité Always On, possède deux noeuds, un dans une zone de disponibilité (AZ) dans une région multizone (MZR) et utilise la réplication synchrone, avec basculement automatique.
• Une connexion réseau, généralement une connexion par liaison directe, connecte les deux clusters.
• Un groupe de disponibilité répartie Always On est configuré et les données sont transférées de la réplique principale du cluster WSFC source vers la réplique principale (le réexpéditeur) dans le cluster WSFC cible.
• Le réexpéditeur est responsable du transfert des données vers la réplique secondaire dans le cluster WSFC cible.

Au cours d'une fenêtre de maintenance, une reprise en ligne manuelle peut être effectuée pour activer le découpage et la base de données principale dans le WSFC cible devient la source de l'accès en lecture / écriture à partir des applications.

Pour plus d'informations, voir Groupes de disponibilité répartis.