Utiliser Log Replay Service (LRS) pour effectuer une migration
Log Replay Service (LRS) est un outil qui permet des migrations personnalisées de bases de données depuis des serveurs SQL Server locaux vers SQL Managed Instance dans le cloud. Il utilise la technologie de copie des journaux de transaction et est utile dans les cas où davantage de contrôle est nécessaire, lorsque la tolérance aux temps d’arrêt est faible, ou quand Azure Data Migration Service ne peut pas être utilisé.
LRS peut être utilisé directement avec PowerShell, les cmdlets CLI ou une API pour générer et orchestrer manuellement des migrations de base de données vers SQL Managed Instance. Voici quelques-unes des raisons d’utiliser LRS :
- Plus de contrôle sur le projet de migration de base de données
- Faible tolérance pour les temps d’arrêt lors du basculement de la migration
- Impossibilité d’installer l’exécutable DMS dans l’environnement
- Absence d’accès aux fichiers pour les sauvegardes de bases de données
- Impossibilité d’ouvrir des ports réseau de l’environnement vers Azure
Comprendre les types de migration
Il existe deux modes de migration disponibles pour LRS.
| Mode | Description | Recommandée pour | Disponibilité de la chaîne de Sauvegarde |
|---|---|---|---|
| Saisie semi-automatique | Termine automatiquement la migration lorsque le dernier fichier de sauvegarde est restauré | Charges de travail passives | Toute la chaîne de sauvegarde doit être disponible à l’avance |
| Continue | Analyse en continu les nouveaux fichiers de sauvegarde et les restaure, ce qui permet un rattrapage des données | Charges de travail actives | La chaîne de sauvegarde peut être ajoutée pendant la migration |
Quel que soit le mode, prévoyez de terminer la migration dans les 30 jours, car le travail LRS sera automatiquement annulé après cette période.
Accéder au processus de migration
Pour exécuter LRS, vous devez disposer de l’un des rôles de contrôle d’accès en fonction du rôle (RBAC) Azure suivants : Propriétaire de l’abonnement, Contributeur SQL Managed Instance ou rôle personnalisé avec l’autorisation Microsoft.Sql/managedInstances/databases/*.
Un compte Stockage Blob Azure est requis et fonctionne comme un stockage intermédiaire pour les fichiers de sauvegarde entre votre instance SQL et votre instance SQL Managed Instance. Pour utiliser le stockage Blob Azure avec un pare-feu, une autre configuration est requise. Vous devez ajouter le sous-réseau SQL Managed Instance aux règles de pare-feu de réseau virtuel du compte de stockage à l’aide de la délégation de sous-réseau MI et du point de terminaison du service de Stockage. En outre, vous pouvez utiliser un jeton SAP ou une identité managée pour accéder à votre compte Stockage Blob Azure, mais pas les deux.
Améliorer les performances de sauvegarde et de restauration
Vous pouvez fractionner des sauvegardes complètes et différentielles en plusieurs fichiers, au lieu d’utiliser un seul fichier, pour améliorer les performances de sauvegarde et de restauration. Cela est dû au fait que plusieurs fichiers peuvent être lus ou écrits en parallèle, ce qui réduit le temps nécessaire pour effectuer l’opération de sauvegarde ou de restauration.
En outre, activer la compression de sauvegarde peut aider à améliorer les vitesses de transfert réseau. Les sauvegardes compressées sont plus petites, ce qui signifie qu’elles prennent moins de temps pour être transférées sur le réseau. Cela peut être particulièrement utile lors du transfert de sauvegardes volumineuses vers ou depuis Azure.
Nous vous recommandons vivement d’activer CHECKSUM pour les sauvegardes, même s’il n’est pas nécessaire. SQL Managed Instance effectue une vérification de l’intégrité des données sur les sauvegardes sans CHECKSUM, ce qui peut augmenter le temps nécessaire pour restaurer la base de données. En activant CHECKSUM, vous pouvez accélérer les opérations de restauration.