Utiliser log Replay Service (LRS) pour migrer
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 journalisation et est utile dans les cas où un contrôle accru est nécessaire, avec peu de tolérance aux interruptions, ou lorsque le service de migration de données Azure ne peut pas être utilisé.
LRS peut être utilisé directement avec PowerShell, les applets de commande CLI ou l’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 interruptions lors de la transition de la migration
- Impossibilité d’installer l’exécutable DMS dans l’environnement
- Absence d'accès aux fichiers de sauvegardes de base 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é pour | Disponibilité de la chaîne de sauvegarde |
|---|---|---|---|
| Autocomplétion | 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.
Sécuriser le 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 Azure (RBAC) 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 Server 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, l’activation de 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 transférer 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 un contrôle d’intégrité 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.