Vue d’ensemble du service LRS avec Azure SQL Managed Instance

  • Article

S’applique à : Azure SQL Managed Instance

Cet article fournit une vue d’ensemble du service LRS (Log Replay Service), que vous pouvez utiliser pour migrer des bases de données de SQL Server vers Azure SQL Managed Instance. LRS est un service cloud gratuit disponible pour Azure SQL Managed Instance et basé sur la technologie d’envoi de journaux SQL Server.

Étant donné que LRS restaure les fichiers de sauvegarde SQL Server standard, vous pouvez l’utiliser pour migrer à partir de SQL Server hébergé n’importe où (localement ou dans n’importe quel cloud) vers Azure SQL Managed Instance.

Pour démarrer votre migration avec LRS, passez en revue Migrer des bases de données avec LRS.

Important

Avant de migrer des bases de données vers le niveau de service Critique pour l’entreprise, tenez compte de ces limitations, qui ne s’appliquent pas au niveau de service Usage général.

Quand utiliser le service LRS

Azure Database Migration Service, l’extension de migration Azure SQL pour Azure Data Studio et LRS utilisent tous la même technologie et les mêmes API de migration sous-jacentes. LRS met en œuvre des migrations personnalisées complexes et des architectures hybrides entre des instances SQL Server locales et des déploiements SQL Managed Instance.

Si vous ne pouvez pas utiliser Azure Database Migration Service ni l’extension Azure SQL pour la migration, vous pouvez utiliser le stockage localement redondant (LRS) directement avec PowerShell, les applets de commande Azure CLI ou les API pour créer et orchestrer manuellement des migrations de base de données vers SQL Managed Instance.

Envisagez d’utiliser LRS dans les cas suivants, quand :

  • Vous avez besoin de plus de contrôle pour votre projet de migration de base de données.
  • Il y a une faible tolérance aux temps d’arrêt lors du basculement de la migration.
  • Le fichier exécutable Database Migration Service ne peut pas être installé dans votre environnement.
  • Le fichier exécutable Database Migration Service ne dispose pas d’accès à vos fichiers de sauvegarde de base de données.
  • L’extension de migration Azure SQL ne peut pas être installée dans votre environnement, ou elle ne peut pas accéder à vos sauvegardes de base de données.
  • Aucun accès au système d’exploitation hôte ou aucun privilège d’administrateur n’est disponible.
  • Il est impossible d’ouvrir des ports de réseau à partir de votre environnement vers Azure.
  • Une limitation de bande passante ou des problèmes de blocage de proxy existent dans votre environnement.
  • Les sauvegardes sont stockées directement dans des comptes Stockage Blob Azure à l’aide de l’option TO URL.
  • Vous devez utiliser des sauvegardes différentielles.

Étant donné que LRS fonctionne en restaurant des fichiers de sauvegarde SQL Server standard, il doit prendre en charge les migrations depuis n’importe quelle source. Les sources suivantes ont été testées :

  • Instance SQL Server locale/boîte
  • SQL Server sur les machines virtuelles
  • Amazon EC2 (Elastic Compute Cloud)
  • Amazon RDS (Relational Database Service) pour SQL Server
  • Google Compute Engine
  • Cloud SQL pour SQL Server - GCP (Google Cloud Platform)
  • Alibaba Cloud RDS pour SQL Server

En cas de problèmes inattendus lors de la migration à partir d’une source non répertoriée, ouvrez un ticket de support pour obtenir de l’aide.

Remarque

  • Nous vous recommandons d’automatiser la migration des bases de données de SQL Server vers Azure SQL Managed Instance en utilisant l’extension de migration Azure SQL pour Azure Data Studio. Envisagez d’utiliser LRS pour orchestrer les migrations lorsque l’extension de migration Azure SQL ne prend pas entièrement en charge vos scénarios.
  • LRS est la seule méthode pour restaurer des sauvegardes différentielles sur des instances managées. Il n’est pas possible de restaurer manuellement des sauvegardes différentielles sur des instances managées, ou de définir manuellement le mode NORECOVERY à l’aide de T-SQL.

Fonctionnement du service LRS

La génération d’une solution personnalisée pour migrer des bases de données vers le cloud avec LRS nécessite plusieurs étapes d’orchestration présentées dans le diagramme et dans le tableau plus loin dans cette section.

La migration consiste à effectuer des sauvegardes de la base de données sur SQL Server et à copier les fichiers de sauvegarde dans un compte Stockage Blob Azure. Les sauvegardes complètes, de fichier journal et différentielles sont prises en charge. Vous utilisez ensuite le service cloud LRS pour restaurer des fichiers de sauvegarde à partir du compte Stockage Blob Azure vers SQL Managed Instance. Le compte Stockage Blob sert de stockage intermédiaire pour les fichiers de sauvegarde entre SQL Server et SQL Managed Instance.

Dans votre compte Stockage Blob ,LRS surveille les nouvelles sauvegardes (différentielles ou de journaux) qui sont ajoutées après la restauration de la sauvegarde complète. LRS restaure ensuite automatiquement ces nouveaux fichiers. Vous pouvez utiliser le service pour surveiller la progression des fichiers de sauvegarde en cours de restauration sur SQL Managed Instance, et arrêter le processus si nécessaire.

LRS ne nécessite pas de convention d’affectation de noms spécifique pour les fichiers de sauvegarde. Il analyse tous les fichiers placés dans le compte Stockage Blob Azure et construit la chaîne de sauvegarde à partir de la lecture des en-têtes de fichier uniquement. Les bases de données sont dans un État de restauration pendant le processus de migration. Les bases de données sont restaurées en mode NORECOVERY. Elles ne peuvent donc pas être utilisées pour les charges de travail de lecture ou d’écriture tant que le processus de migration n’est pas terminé.

Si vous effectuez la migration de plusieurs bases de données, vous devez :

  • Placez des fichiers de sauvegarde pour chaque base de données dans un dossier distinct sur le compte Stockage Blob dans une structure de fichier plat. Par exemple, utilisez des dossiers de base de données distincts : blobcontainer/database1/files, blobcontainer/database2/files, etc.
  • N’utilisez pas de dossiers imbriqués dans les dossiers de bases de données, car cette structure n’est pas prise en charge. Par exemple, n’utilisez pas de sous-dossiers tels que blobcontainer/database1/subfolder/files.
  • Démarrez LRS séparément pour chaque base de données.
  • Spécifiez des chemins d’accès URI différents vers des dossiers de bases de données distincts sur le compte Stockage Blob.

Bien que non obligatoire, l’activation de CHECKSUM pour les sauvegardes est fortement recommandée. La restauration des bases de données sans CHECKSUM prend plus de temps, car SQL Managed Instance effectue une vérification de l’intégrité sur les sauvegardes qui sont restaurées sans la fonctionnalité CHECKSUM activée.

Pour plus d’informations, consultez Migrer des bases de données depuis SQL Server vers SQL Managed Instance à l’aide de Log Replay Service.

Attention

Il est vivement recommandé d’effectuer des sauvegardes sur SQL Server avec CHECKSUM activé, au risque sinon de restaurer une base de données endommagée sur Azure.

Migration en mode autocomplétion ou en mode continu

Vous pouvez démarrer LRS en mode autocomplétion ou en mode continu .

Utilisez le mode autocomplétion lorsque vous disposez de l’ensemble de la chaîne de sauvegarde générée à l’avance et si vous ne prévoyez pas d’ajouter des fichiers une fois la migration démarrée. Ce mode de migration est recommandé pour les charges de travail passives qui ne nécessitent pas de rattrapage de données. Chargez tous les fichiers de sauvegarde dans le compte Stockage Blob et démarrez la migration en mode autocomplétion. La migration s’achèvera automatiquement une fois le dernier fichier de sauvegarde spécifié restauré. La base de données migrée sera alors disponible pour l’accès en lecture et écriture sur SQL Managed Instance.

Si vous prévoyez de continuer à ajouter de nouveaux fichiers de sauvegarde pendant la migration, utilisez le mode continu. Nous recommandons ce mode pour les charges de travail actives qui nécessitent un rattrapage des données. Chargez la chaîne de sauvegarde actuellement disponible dans le compte Stockage Blob, démarrez la migration en mode continu et continuez d’ajouter de nouveaux fichiers de sauvegarde à partir de votre charge de travail en fonction des besoins. Le système analyse à intervalles réguliers le dossier du Stockage Blob Azure, et restaure tout nouveau fichier de sauvegarde différentielle ou de journal qu’il trouve.

Lorsque vous êtes prêt pour le basculement, arrêtez la charge de travail sur votre instance SQL Server, générez le dernier fichier de sauvegarde, puis chargez-le. Assurez-vous que le dernier fichier de sauvegarde a été restauré en vérifiant que la dernière sauvegarde en queue de journal apparaît comme restaurée sur le déploiement SQL Managed Instance. Ensuite, lancez le basculement manuel. Lors de l’étape finale du basculement, la base de données est mise en ligne et disponible pour accès en lecture et écriture sur SQL Managed Instance.

Une fois le service LRS arrêté, soit automatiquement avec l’autocomplétion, soit manuellement lors du basculement, vous ne pouvez pas reprendre le processus de restauration pour une base de données qui a été mise en ligne dans SQL Managed Instance. Par exemple, une fois la migration terminée, vous ne pouvez plus restaurer de sauvegardes différentielles supplémentaires pour une base de données en ligne. Pour restaurer d’autres fichiers de sauvegarde une fois la migration terminée, vous devez supprimer la base de données de l’instance managée et recommencer la migration depuis le début.

Workflow de la migration

Un flux de travail de migration classique est présenté dans l’image suivante, et les étapes sont décrites dans le tableau.

Vous ne devez utiliser le mode autocomplétion que lorsque tous les fichiers de chaîne de sauvegarde sont disponibles à l’avance. Nous recommandons ce mode pour les charges de travail passives ne nécessitant aucun rattrapage de données.

Utilisez une migration en mode continu quand vous ne disposez pas d’une chaîne de sauvegarde entière à l’avance, et envisagez d’ajouter de nouveaux fichiers de sauvegarde en cours de migration. Nous recommandons ce mode pour les charges de travail actives nécessitant un rattrapage de données.

Diagramme qui illustre les étapes de l’orchestration du service LRS pour SQL Managed Instance.

Opération Détails
1. Copiez les sauvegardes de base de données de l’instance SQL Server vers le compte Stockage Blob. Copiez les sauvegardes complètes, différentielles et de journal de l’instance SQL Server vers le conteneur Stockage Blob en utilisant AzCopy ou l’Explorateur Stockage Azure.

Utilisez n’importe quel nom de fichier. LRS ne nécessite pas une convention d’affectation de noms de fichiers.

Lors de la migration de plusieurs bases de données, vous devez avoir un dossier distinct pour chaque base de données.
2. Démarrez LRS dans le Cloud. Vous pouvez redémarrer le service avec PowerShell (start-azsqlinstancedatabaselogreplay) ou Azure CLI (cmdlet az_sql_midb_log_replay_start). Choisissez entre les modes de migration autocomplétion et continu.

Démarrez LRS séparément pour chaque base de données qui pointe vers un dossier de sauvegarde dans le compte Stockage Blob.

Une fois démarré, le service prend les sauvegardes dans le conteneur Stockage Blob et commence à les restaurer dans SQL Managed Instance.

Lors du démarrage en mode autocomplétion, LRS restaure toutes les sauvegardes jusqu’au dernier fichier de sauvegarde spécifié. Tous les fichiers de sauvegarde doivent être chargés à l’avance et il n’est pas possible d’en ajouter de nouveaux pendant la migration. Ce mode est recommandé pour les charges de travail passives ne nécessitant aucun rattrapage de données.

Lors du démarrage en mode continu, LRS restaure toutes les sauvegardes initialement chargées, puis surveille les nouveaux fichiers chargés dans le dossier. Le service applique continuellement les journaux en fonction de la chaîne du numéro séquentiel dans le journal (LSN) jusqu’à ce qu’il soit arrêté manuellement. Nous recommandons ce mode pour les charges de travail actives nécessitant un rattrapage de données.
2.1. Superviser la progression de l’opération. Vous pouvez surveiller la progression de l’opération de restauration en cours avec PowerShell (azsqlinstancedatabaselogreplay) ou Azure CLI (cmdlet az_sql_midb_log_replay_show). Pour suivre des détails supplémentaires d’une requête ayant échoué, utilisez la commande PowerShell Get-AzSqlInstanceOperation ou utilisez la commande Azure CLI az sql mi op show.
2.2. Arrêter l’opération si nécessaire (facultatif). Si vous devez arrêter le processus de migration, utilisez PowerShell (stop-azsqlinstancedatabaselogreplay) ou Azure CLI (az_sql_midb_log_replay_stop).

L’arrêt de l’opération entraîne la suppression de la base de données que vous restaurez sur SQL Managed Instance. Après l’arrêt d’une opération, vous ne pouvez pas reprendre LRS pour une base de données. Vous devez redémarrer le processus de migration du début.
3. Basculez le Cloud lorsque vous êtes prêt. Si LRS a été démarré en mode autocomplétion, la migration s’achève automatiquement une fois le dernier fichier de sauvegarde spécifié restauré.

Si LRS a été démarré en mode continu, arrêtez l’application et la charge de travail. Chargez la dernière sauvegarde de la fin de journal dans le déploiement Stockage Blob Azure. Assurez-vous que la dernière sauvegarde en queue de journal a été restaurée sur l’instance managée. Terminez le basculement en lançant une opération LRS complete avec PowerShell (complete-azsqlinstancedatabaselogreplay) ou Azure CLI az_sql_midb_log_replay_complete. Cette opération arrête LRS et met la base de données en ligne pour les charges de travail en lecture et en écriture sur SQL Managed Instance.

Redirigez la chaîne de connexion d’application de l’instance SQL Server vers le déploiement SQL Managed Instance. Vous devez orchestrer cette étape vous-même, soit via une modification manuelle de la chaîne de connexion dans votre application, soit automatiquement (par exemple, si votre application peut lire la chaîne de connexion à partir d’une propriété ou d’une base de données).

Important

Après le basculement, SQL Managed Instance avec le niveau de service Critique pour l'entreprise peut prendre beaucoup plus de temps que Usage général pour être disponible, car trois réplicas secondaires doivent être créées pour le groupe de disponibilité. La durée de cette opération dépend de la taille des données. Pour plus d’informations, consultez Durée des opérations de gestion.

Migration de bases de données volumineuses

Si vous migrez des bases de données volumineuses de plusieurs To, tenez compte des observations suivantes :

  • Un travail LRS unique peut s’exécuter pendant un maximum de 30 jours. À l’expiration de cette période, le travail est automatiquement annulé.
  • Des mises à jour système auront pour effet d’interrompre et de prolonger les travaux de migration de longue durée. Nous vous recommandons vivement d’utiliser une fenêtre de maintenance pour planifier les mises à jour système. Planifiez votre migration autour de la fenêtre de maintenance planifiée.
  • Les travaux de migration qui sont interrompus par des mises à jour système sont automatiquement suspendus et repris pour des instances managées de niveau Usage général, puis redémarrés pour des instances managées de niveau Critique pour l’entreprise. Ces mises à jour affecteront la plage de temps de votre migration.
  • Pour augmenter la vitesse de chargement de vos fichiers de sauvegarde SQL Server sur le compte Stockage Blob, si la bande passante réseau de votre infrastructure est suffisante, envisagez d’utiliser la parallélisation avec plusieurs threads.

Démarrer la migration

Pour démarrer la migration, démarrez LRS. Vous pouvez démarrer le service en mode autocomplétion ou en mode continu. Pour plus d’informations, consultez Effectuer une migration avec LRS.

  • Mode Autocomplétion. Lorsque vous utilisez le mode autocomplétion, la migration se termine automatiquement lorsque le dernier fichier de sauvegarde spécifié a été restauré. Cette option :

    • Cette option nécessite que la chaîne de sauvegarde toute entière soit disponible à l’avance et chargée dans le compte Stockage Blob Azure.
    • Elle n’autorise pas l’ajout de nouveaux fichiers de sauvegarde durant la migration.
    • Elle requiert que la commande de démarrage spécifie le nom de fichier du dernier fichier de sauvegarde.

    Nous vous recommandons d’utiliser le mode autocomplétion pour les charges de travail passives ne nécessitant pas un rattrapage de données.

  • Mode continu. Lorsque vous utilisez le mode continu, le service analyse continuellement le dossier Stockage Blob Azure et restaure tout nouveau fichier de sauvegarde ajouté pendant la migration.

    La migration ne s’achève qu’après que le basculement manuel a été demandé.

    Vous devez utiliser une migration en mode continu quand vous ne disposez pas d’une chaîne de sauvegarde entière à l’avance, et envisagez d’ajouter de nouveaux fichiers de sauvegarde en cours de migration.

    Nous recommandons l’utilisation du mode continu pour les charges de travail actives nécessitant un rattrapage de données.

Planifiez l’achèvement d’un travail de migration LRS unique dans un délai maximal de 30 jours. À l’expiration de cette période, le travail LRS est automatiquement annulé.

Remarque

Lorsque vous migrez plusieurs bases de données, chaque base de données doit se trouver dans son propre dossier. LRS doit être démarré séparément pour chaque base de données qui pointe vers le chemin d’URI complet du conteneur Stockage Blob Azure et le dossier de la base de données individuelle. Des dossiers imbriqués dans des dossiers de base de données ne sont pas pris en charge.

Limitations de LRS

Pour plus d’informations, passez en revue les limitations lors de l’utilisation de LRS.

Étapes suivantes