Migrer un serveur MySQL local avec l’interface de ligne de commande d’importation d’Azure Database pour MySQL
Il est temps de migrer le serveur MySQL local vers un serveur flexible Azure Database pour MySQL. Vous avez décidé d’effectuer une migration hors connexion, car les paramètres réseau empêchent une connexion directe entre les serveurs source et cible. Le diagramme suivant récapitule la procédure :
Prérequis
Sur le serveur source, vérifiez que les paramètres suivants sont configurés :
-
lower_case_table_names = 1 innodb_file_per_table = ON innodb_page_size = 16348 (MySQL Default)
Le nom de l’espace de table système doit être
ibdata1
.La taille de l’espace de table système doit être supérieure ou égale à 12 Mo. (MySQL par défaut)
Seul le moteur INNODB est pris en charge.
-
Il vous faut un conteneur Stockage Blob Azure. Si vous n’avez pas de conteneur approprié, créez-en un avec ce guide de démarrage rapide. Vous avez besoin du jeton de signature d’accès partagé (SAP) du conteneur d’objets blob Azure. Pour optimiser les performances, conservez le serveur flexible cible et le stockage dans la même région.
Vous devez arrêter votre application pour empêcher les modifications apportées à la base de données.
Procédure
Effectuez une sauvegarde physique de votre base de données MySQL. Nous utilisons l’outil XtraBackup open source de Percona.
Installez l’outil selon ces instructions (pour MySQL 8.0).
Créer une sauvegarde complète, par exemple :
xtrabackup --backup --target-dir=/data/backups/
Chargez le fichier de sauvegarde dans le stockage Blob Azure, en suivant ces étapes.
Déclenchez l’importation en exécutant cette commande après avoir renseigné des variables. Vous pouvez également modifier la taille de calcul en modifiant Standard_D2ds_v4.
-
az mysql flexible-server import create --data-source-type "azure_blob" --data-source $BLOB_DATA_URL --data-source-backup-dir "mysql_backup_percona" –-data-source-token $SAS_TOKEN --resource-group $RESOURCE_GROUP --name $FLEXIBLE_SERVER_NAME –-sku-name Standard_D2ds_v4 --tier GeneralPurpose –-version 8.0 -–location westus --auto-scale-iops Enabled
Attendez-vous à ce que l’importation prenne plus de temps en fonction de la taille du fichier de sauvegarde. L’importation d’un fichier de sauvegarde de 1 Gio prend environ une demi-minute, tandis que celle d’un fichier de 1 To prend environ 23 minutes.
-
Gardez à l’esprit les limitations suivantes :
- Les utilisateurs et les privilèges ne sont pas migrés. Vous devez vider manuellement les utilisateurs et les privilèges pour migrer les connexions une fois l’opération d’importation terminée.
- La haute disponibilité n’est pas disponible lors de l’importation. Activez donc la haute disponibilité une fois la migration terminée.
Une fois que les utilisateurs et les privilèges sont migrés, connectez vos applications au serveur flexible. La migration est alors terminée.
Conseil
Sinon, si vous effectuez une migration en ligne, vous avez effectué l’exportation et l’importation comme expliqué précédemment, puis configuré la réplication de la source vers la cible. Lorsque la cible est entièrement rattrapée à la source, vous avez coupé l’application avant d’arrêter la base de données source.