Préparer l’environnement pour la migration LRS - Migration SQL Server dans Azure Arc

S'applique à :SQL Server

Cet article vous aide à préparer votre environnement pour une migration Log Replay Service (LRS) de votre instance SQL Server activée par Azure Arc vers Azure SQL Managed Instance dans le Portail Azure.

Avec LRS, vous pouvez migrer vos bases de données SQL Server vers Azure SQL Managed Instance à l’aide de la sauvegarde et de la restauration via la copie des journaux de transaction (migration en ligne) :

Prerequisites

Pour migrer vos bases de données SQL Server vers Azure SQL Managed Instance via le portail Azure, vous avez besoin des prérequis suivants :

• Un abonnement Azure actif. Si vous n’en avez pas, créez un compte gratuit.
• Instance prise en charge de SQL Server activée par Azure Arc avec l’extension Azure pour la version de SQL Server ou une version 1.1.3238.349 ultérieure. Vous pouvez mettre à niveau votre extension à l’aide du portail Azure ou d’Azure CLI.

Versions de SQL Server prises en charge

La migration avec LRS fonctionne avec chaque édition de SQL Server sur Windows. Bien que la migration vers les niveaux de service Usage général et Critique pour l’entreprise de SQL Managed Instance soit prise en charge, la migration directe vers le niveau de service Critique pour l’entreprise présente certaines limitations importantes à prendre en compte.

Le tableau suivant répertorie les versions minimales de SQL Server prises en charge pour LRS :

La migration inverse est prise en charge uniquement vers SQL Server 2025 et SQL Server 2022 à partir d’instances managées SQL avec la stratégie de mise à jour correspondante. Vous pouvez inverser manuellement une migration via d’autres outils tels que la sauvegarde et la restauration natives, ou configurer manuellement un lien dans SSMS.

Permissions

Cette section décrit les autorisations dont vous avez besoin pour migrer votre instance SQL Server vers SQL Managed Instance via le portail Azure.

Sur l’instance SQL Server source, vous avez besoin des autorisations suivantes :

• Si vous activez le privilège minimum, les autorisations nécessaires telles que sysadmin sont accordées selon les besoins pendant le processus de migration de base de données.
• Si vous ne pouvez pas utiliser le privilège minimum, vous avez besoin d’autorisations sysadmin sur l’instance SQL Server source.

Pour migrer avec LRS, vous avez besoin de l’une des autorisations suivantes sur la cible SQL Managed Instance :

• Rôle de Contributeur SQL Managed Instance
• Un rôle avec l’autorisation suivante : Microsoft.Sql/managedInstances/databases/*

Créez un compte de stockage.

Vous utilisez un compte Stockage Blob Azure comme stockage intermédiaire pour les fichiers de sauvegarde entre votre instance de SQL Server et votre déploiement SQL Managed Instance. Le compte de stockage doit se trouver dans le même abonnement Azure que votre cible SQL Managed Instance.

Pour créer un nouveau compte de stockage et un conteneur de blobs à l'intérieur de ce compte :

1. Créez un compte de stockage :
   1. Recherchez des comptes de stockage dans le portail Azure, puis sélectionnez Créer.
   2. Sous l’onglet Informations de base , sélectionnez votre abonnement et votre groupe de ressources. La région doit être identique à votre cible SQL Managed Instance.
   3. Laissez le type de stockage préféré vide.
   4. Utilisez les paramètres par défaut pour le reste des onglets, puis sélectionnez Vérifier + créer.
   5. Une fois la validation réussie, sélectionnez Créer.
2. Créez un conteneur blob dans le compte de stockage.
   1. Accédez à votre nouveau compte de stockage dans le portail Azure.
   2. Sous Stockage de données, sélectionnez Conteneurs.
   3. Utilisez Ajouter un conteneur pour ouvrir le volet Nouveau conteneur .
   4. Entrez un nom pour votre conteneur, laissez les options par défaut, puis sélectionnez Créer pour créer votre conteneur.
3. (Facultatif) Si votre stockage Azure se trouve derrière un pare-feu, votre stockage Blob Azure nécessite une configuration supplémentaire une fois que votre instance managée SQL est provisionnée.

Accorder des autorisations pour le stockage Blob Azure

La migration SQL Server dans Azure Arc avec LRS utilise une identité managée pour s’authentifier auprès d’Azure Blob Storage.

Vous devez accorder les autorisations suivantes :

• Accordez à l’utilisateur l’accès au compte de stockage dans lequel vous envisagez de stocker des sauvegardes pendant le processus de migration.
• Accordez à l’utilisateur l’accès au groupe de ressources qui contient le compte de stockage.
• Accordez l'accès au compte de stockage à l'identité managée une fois que votre instance SQL managée est provisionnée.

Accorder à l’utilisateur l’accès au compte de stockage

Pour accéder aux sauvegardes de base de données pendant le processus de migration, assignez à l’utilisateur qui se connecte au portail Azure et réalise la migration le rôle Lecteur de données Blob de stockage pour le compte de stockage qui contient les sauvegardes.

Pour attribuer le rôle, procédez comme suit :

1. Dans le portail Azure, accédez au groupe de ressources qui contient votre compte de stockage.

2. Sélectionnez Contrôle d’accès (IAM) à partir du menu ressource.

3. Utilisez + Ajouter pour sélectionner Ajouter une attribution de rôle et ouvrez le volet Ajouter une attribution de rôle .

4. Recherchez et sélectionnez le rôle Lecteur de données blob de stockage. Ensuite, sélectionnez Suivant.

   

5. Utilisez + Sélectionner des membres pour ouvrir le volet Sélectionner des membres et recherchez le compte d’utilisateur de la personne effectuant la migration. Si plusieurs personnes migrent des données, accordez à tous ces utilisateurs cet accès. Sélectionnez le compte d’utilisateur, puis utilisez Sélectionner pour enregistrer votre sélection. Cochez l’option permettant d’attribuer l’accès à l’utilisateur, au groupe ou au principal du service.

6. Sélectionnez Vérifier + affecter pour accéder à l’onglet Vérifier + affecter , puis sélectionnez Vérifier + attribuer à nouveau pour terminer l’attribution de rôle.

Accorder à l’utilisateur l’accès au groupe de ressources

Pour accéder aux sauvegardes de base de données pendant le processus de migration, l’utilisateur qui se connecte au portail Azure et effectue la migration doit être affecté au rôle Lecteur sur le groupe de ressources qui contient le compte de stockage.

Pour attribuer le rôle, procédez comme suit :

1. Dans le portail Azure, accédez au groupe de ressources qui contient votre compte de stockage.

2. Sélectionnez Contrôle d’accès (IAM) à partir du menu ressource.

3. Utilisez + Ajouter pour sélectionner Ajouter une attribution de rôle et ouvrez le volet Ajouter une attribution de rôle .

4. Recherchez et sélectionnez le rôle Lecteur . Ensuite, sélectionnez Suivant.

   

5. Utilisez + Sélectionner des membres pour ouvrir le volet Sélectionner des membres et recherchez le compte d’utilisateur de la personne effectuant la migration. Si plusieurs personnes migrent des données, accordez à tous ces utilisateurs cet accès. Sélectionnez le compte d’utilisateur, puis utilisez Sélectionner pour enregistrer votre sélection. Cochez l’option permettant d’attribuer l’accès à l’utilisateur, au groupe ou au principal du service , puis utilisez Suivant pour continuer.

6. Sous l’onglet Type d’affectation , définissez le type d’affectation sur Actif et la durée de l’affectation sur Permanent :

   

7. Sélectionnez Vérifier + affecter pour accéder à l’onglet Vérifier + affecter , puis sélectionnez Vérifier + attribuer à nouveau pour terminer l’attribution de rôle.

Accorder à l’identité managée l’accès au compte de stockage

Une fois que votre instance managée SQL est provisionnée, vous devez affecter l’identité managée de votre instance managée SQL au rôle Lecteur de données blob de stockage afin qu’il puisse accéder à votre compte Stockage Blob Azure pendant le processus de migration.

Tout d’abord, vous devez déterminer le type d’identité managée utilisée par votre instance managée SQL. Pour ce faire, procédez comme suit :

1. Accédez à votre SQL Managed Instance dans le portail Azure.
2. Sous Sécurité, sélectionnez Identité.
   1. Si, sous Identité managée affectée par l’utilisateur, aucune identité managée affectée par l’utilisateur n’est trouvée, votre instance managée SQL utilise l’identité managée affectée par le système par défaut.
   2. Si vous voyez une entrée dans le champ Identité principale , votre instance managée SQL utilise une identité managée affectée par l’utilisateur personnalisé. Notez cette identité à utiliser à l’étape où vous sélectionnez cette identité managée lors de l’octroi de l’accès lecteur de données blob de stockage au compte de stockage.

Pour accorder l’accès au compte de stockage, procédez comme suit :

1. Accédez au compte Stockage Blob Azure dans le portail Azure que vous envisagez d’utiliser pour la migration.
2. Sélectionnez Contrôle d’accès (IAM) à partir du menu ressource.
3. Utilisez + Ajouter pour sélectionner Ajouter une attribution de rôle et ouvrez le volet Ajouter une attribution de rôle .
4. Recherchez et sélectionnez le rôle Lecteur de données blob de stockage. Ensuite, sélectionnez Suivant.
5. Sous Attribuer l’accès pour vérifier l’option Identité managée .
6. Utilisez Sélectionner des membres pour ouvrir le volet Sélectionner des membres .
7. Si votre instance managée SQL utilise l’identité managée affectée par le système par défaut :
   1. Sous Identité managée, sélectionnez INSTANCE managée SQL.
   2. Recherchez et sélectionnez le nom de votre instance managée SQL.
   3. Utilisez Sélectionner pour enregistrer votre sélection.
8. Si votre instance managée SQL utilise une identité managée affectée par l’utilisateur :
   1. Sous Identité managée, sélectionnez Identité managée affectée par l’utilisateur.
   2. Recherchez le nom de l’identité principale que vous avez noté précédemment dans la page Identité de votre instance managée SQL , puis sélectionnez-la.
   3. Utilisez Sélectionner pour enregistrer votre sélection.
9. Sélectionnez Vérifier + affecter pour accéder à l’onglet Vérifier + affecter , puis sélectionnez Vérifier + attribuer à nouveau pour terminer l’attribution de rôle.

Une fois que vous avez chargé au moins une sauvegarde complète sur ce compte de stockage, vous pouvez exécuter la commande suivante sur votre instance managée SQL pour vérifier qu’elle peut accéder à votre compte Stockage Blob Azure :

RESTORE HEADERONLY
    FROM URL = 'https://<mystorageaccountname>.blob.core.windows.net/<containername>/full_0_0.bak';

Charger des sauvegardes sur votre compte Stockage Blob

Lorsque votre conteneur d’objets blob est prêt et que vous avez confirmé que votre instance managée SQL peut accéder au conteneur, vous pouvez commencer à charger vos sauvegardes dans votre compte Stockage Blob Azure. Lorsque toutes vos sauvegardes sont chargées sur votre compte de stockage, vous êtes prêt à poursuivre la migration.

Pour charger vos sauvegardes dans Azure :

• Effectuez des sauvegardes sur une instance SQL Server.
• Copiez vos sauvegardes dans votre compte Stockage Blob.

Envisagez les meilleures pratiques suivantes :

• Effectuez des sauvegardes en utilisant les options COMPRESSION et CHECKSUM pour réduire la taille des fichiers de sauvegarde et éviter la migration d'une base de données corrompue.
• Effectuez des sauvegardes dans des lots plus petits.
• Utilisez des threads de chargement parallèles.
• Faites en sorte que le dernier fichier de sauvegarde soit aussi petit que possible.
• Pour migrer plusieurs bases de données à l’aide du même conteneur Stockage Blob Azure, placez tous les fichiers de sauvegarde d’une base de données individuelle dans un dossier distinct à l’intérieur du conteneur. Utilisez la structure de fichier plat pour chaque dossier de base de données. L’imbrication de dossiers dans des dossiers de base de données n’est pas prise en charge.

Effectuer des sauvegardes sur une instance SQL Server

Configurez les bases de données que vous voulez migrer sur le mode de récupération complète pour autoriser les sauvegardes de fichier journal.

-- To permit log backups, before the full database backup, modify the database to use the full recovery
USE master;

ALTER DATABASE SampleDB
SET RECOVERY FULL;
GO

Si vous n’avez pas encore de sauvegardes existantes, utilisez les exemples de scripts T-SQL suivants pour effectuer manuellement des sauvegardes complètes, différentielles et de journalisation de votre base de données dans le stockage local. CHECKSUM n’est pas obligatoire, mais il est recommandé pour éviter la migration d'une base de données endommagée et garantir des temps de restauration plus rapides.

L’exemple suivant prend une sauvegarde complète de base de données sur le disque local :

-- Take full database backup to local disk
BACKUP DATABASE [SampleDB]
    TO DISK = 'C:\BACKUP\SampleDB_full.bak'
    WITH INIT, COMPRESSION, CHECKSUM;
GO

L’exemple suivant prend une sauvegarde différentielle sur le disque local :

-- Take differential database backup to local disk
BACKUP DATABASE [SampleDB]
    TO DISK = 'C:\BACKUP\SampleDB_diff.bak'
    WITH DIFFERENTIAL, COMPRESSION, CHECKSUM;
GO

L’exemple suivant prend une sauvegarde du journal des transactions sur le disque local :

-- Take transactional log backup to local disk
BACKUP LOG [SampleDB]
    TO DISK = 'C:\BACKUP\SampleDB_log.trn'
    WITH COMPRESSION, CHECKSUM;
GO

Copiez des sauvegardes sur votre compte de stockage Blob

Une fois vos sauvegardes prêtes et que vous souhaitez commencer à migrer des bases de données vers une instance managée SQL à l’aide de LRS, utilisez les approches suivantes pour copier des sauvegardes existantes vers votre compte stockage Blob :

• Téléchargez et installez AzCopy.
• Téléchargez et installez l'Explorateur Stockage Microsoft Azure.
• Utilisez Explorateur Stockage dans le portail Azure.

Limites

Les limitations de LRS s’appliquent aux migrations via le portail Azure.

Limitations lors de la migration vers le niveau de service Critique pour l’entreprise

Lors de la migration vers SQL Managed Instance dans le niveau de service Critique pour l’entreprise, tenez compte des limitations suivantes :

• Lors de la migration de bases de données volumineuses, vous pouvez rencontrer un temps d’arrêt considérable, car les bases de données ne sont pas disponibles après le basculement pendant qu'elles sont envoyées vers des réplicas secondaires du niveau de service Critique pour l’entreprise. Les solutions de contournement sont répertoriées dans la section basculement prolongé.
• La migration redémarre automatiquement à partir du début si le basculement non planifié, la mise à jour système ou le correctif de sécurité interrompt la migration. Cette limitation rend difficile la planification d’une migration prévisible sans surprises de dernière minute.

Basculement plus long dans le niveau de service Critique pour l’entreprise

Si vous migrez vers une instance managée SQL dans le niveau de service Critique pour l’entreprise, tenez compte du délai d’ajout des bases de données sur le réplica principal, pendant que les bases de données sont allouées à des réplicas secondaires. Ce délai est particulièrement vrai pour les bases de données plus volumineuses.

La migration vers SQL Managed Instance dans le niveau de service Critique pour l’entreprise prend plus de temps que dans le niveau de service Usage général. Une fois le basculement vers Azure effectué, les bases de données ne sont pas disponibles jusqu'à ce qu'elles soient ensemencées du réplica principal vers les trois réplicas secondaires. Le processus d’amorçage peut prendre une durée prolongée en fonction de la taille de votre base de données. Plus la base de données est grande, plus l’essaimage des réplicas secondaires peut prendre de temps (jusqu’à plusieurs heures).

S’il est important que les bases de données soient disponibles dès la fin du basculement, tenez compte des solutions de contournement suivantes :

• Migrez d’abord vers le niveau de service Usage général, puis effectuez une mise à niveau vers le niveau de service Critique pour l’entreprise . La mise à niveau de votre niveau de service est une opération en ligne qui maintient vos bases de données accessibles jusqu’à un court basculement, qui constitue la dernière étape de l’opération de mise à niveau.
• Utilisez la liaison Managed Instance pour effectuer une migration en ligne vers une instance Critique pour l’entreprise sans avoir à attendre que les bases de données soient disponibles après le basculement.

La surveillance de la migration via le portail Azure est disponible uniquement pour les instances SQL Server qui répondent aux exigences de gestion des licences.

Résolution des problèmes courants

Pour résoudre les problèmes courants lors de la migration vers Azure SQL Managed Instance, consultez Résoudre les problèmes de migration.

Contenu connexe

• Migration sql Server dans Azure Arc
• Préparer l’environnement pour une migration de liens Managed Instance
• Vue d’ensemble de SQL Server activée par Azure Arc
• Commentaires sur l’expérience de migration directement vers le groupe de produits
• Migration vers Azure SQL Managed Instance - Migration SQL Server dans Azure Arc