Migrer d’un serveur unique vers un serveur flexible Azure Database pour MySQL en utilisant l’interface CLI d’importation Azure Database pour MySQL
S’APPLIQUE À : 
Azure Database pour MySQL – Serveur unique
L’interface CLI d’importation Azure Database pour MySQL (disponibilité générale) vous permet de migrer votre serveur unique vers un serveur flexible Azure Database pour MySQL en toute transparence. Elle utilise une technologie instantanée de sauvegarde et de restauration qui offre un chemin de migration simple et rapide de restauration des fichiers de données physiques du serveur source vers le serveur cible. Après l’opération d’importation, vous pouvez bénéficier des avantages du serveur flexible, notamment de meilleures performances et d’un meilleur prix, d’un contrôle précis sur la configuration de la base de données, et de fenêtres de maintenance personnalisées.
En fonction des entrées utilisateur, elle prend la responsabilité d’approvisionner votre serveur flexible cible, puis d’effectuer la sauvegarde du serveur source et la restauration sur la cible. Il copie les fichiers de données, les paramètres du serveur, les règles de pare-feu et les propriétés du serveur (niveau, version, nom de la référence SKU, taille du stockage, emplacement, sauvegarde géoredondante, accès public, étiquettes, croissance automatique, jours de conservation des sauvegardes, utilisateur administrateur et mot de passe administrateur) depuis une instance serveur unique vers une instance serveur flexible.
L’interface CLI d’importation Azure Database pour MySQL prend en charge une migration avec un temps d’arrêt quasi-nul en effectuant d’abord une opération d’importation hors connexion et, par conséquent, les utilisateurs peuvent configurer la réplication de données entre la source et la cible pour effectuer une migration en ligne.
Ce tutoriel montre comment utiliser la commande CLI d’importation Azure Database pour MySQL pour migrer votre serveur unique vers un serveur flexible Azure Database pour MySQL.
Nouveautés
- L’opération d’importation Azure Database pour MySQL pour les serveurs uniques avec l’architecture de stockage hérité (stockage d’usage général V1) est désormais prise en charge. Vous devez définir le paramètre log_bin=ON pour votre instance serveur unique avec le stockage hérité avant de lancer l’opération d’importation. Pour ce faire, créez un réplica en lecture pour votre instance de serveur unique, puis supprimez-le. Cette opération définit le paramètre log_bin sur ON et vous pouvez ensuite déclencher une opération d’importation pour migrer vers un serveur flexible. (février 2024)
Lancement d’Azure Cloud Shell
Azure Cloud Shell est un interpréteur de commandes interactif et gratuit que vous pouvez utiliser pour exécuter les étapes de cet article. Il contient des outils Azure courants préinstallés et configurés pour être utilisés avec votre compte.
Pour ouvrir Cloud Shell, sélectionnez Essayer en haut à droite d’un bloc de code. Vous pouvez également ouvrir Cloud Shell dans un onglet distinct du navigateur en accédant à https://shell.azure.com/bash. Sélectionnez Copier pour copier les blocs de code, collez-les dans Cloud Shell et sélectionnez Entrée pour les exécuter.
Si vous préférez installer et utiliser l’interface de ligne de commande localement, ce tutoriel requiert la version 2.54.0 ou ultérieure d’Azure CLI. Exécutez az --version pour trouver la version. Si vous devez installer ou mettre à niveau, voir Installer Azure CLI.
Paramétrage
Vous devez vous connecter à votre compte à l’aide de la commande az login. Notez la propriété id, qui fait référence à l’ID d’abonnement de votre compte Azure.
az login
Sélectionnez l’abonnement spécifique dans lequel le serveur unique source Azure Database pour MySQL se trouve sous votre compte à l’aide de la commande az account set. Notez la valeur id figurant dans la sortie de la commande az login comme valeur de l’argument abonnement de la commande. Si vous avez plusieurs abonnements, choisissez l’abonnement approprié dans lequel réside le serveur unique source Azure Database pour MySQL. Pour obtenir l’ensemble de vos abonnements, utilisez az account list.
az account set --subscription <subscription id>
Limitations et conditions préalables
Si votre serveur unique Azure Database pour MySQL source a une SKU de base, envisagez de spécifier la SKU dans la commande d’importation comme Usage général pour atténuer les problèmes de mémoire insuffisante. Vous pouvez remettre la SKU en Burstable sur l’instance de serveur flexible migrée après la migration.
Si votre serveur unique Azure Database pour MySQL source possède la version du moteur v8.x, veillez à mettre à niveau la version du pilote client .NET de votre serveur source vers la version 8.0.32 pour éviter toute incompatibilité d’encodage après la migration vers un serveur flexible.
Le serveur unique source Azure Database pour MySQL et le serveur flexible cible Azure Database pour MySQL doivent se trouver dans le même abonnement, le même groupe de ressources, la même région et avoir la même version de MySQL. L’importation entre abonnements, groupes de ressources, régions et versions n’est pas possible.
L’interface CLI d’importation Azure Database pour MySQL prend en charge les versions 5.7 et 8.0 de MySQL. Si vous utilisez une autre version majeure de MySQL sur serveur unique, veillez à mettre à niveau votre version sur votre instance serveur unique avant de déclencher la commande d’importation.
Si l’instance Azure Database pour MySQL – Serveur unique a le paramètre de serveur « lower_case_table_names » défini sur 2 et que votre application a utilisé des tables de partition, l’opération d’importation entraîne des tables de partition endommagées. La recommandation consiste à définir « lower_case_table_names » sur 1 pour votre instance Azure Database pour MySQL - Serveur unique afin de poursuivre l’opération d’importation MySQL sans corruption.
L’importation vers un serveur flexible Azure MySQL existant n’est pas prise en charge. La commande CLI lance l’importation d’un nouveau serveur flexible Azure MySQL.
Si le serveur cible flexible est approvisionné sans HA (haute disponibilité désactivée) lors de la mise à jour des paramètres de commande CLI, il peut ensuite être basculé vers une haute disponibilité de même zone, mais pas vers une haute disponibilité de redondance interzone.
Pour les instances de serveur unique activées par CMK, la commande d’importation Azure Database pour MySQL vous demande de fournir des paramètres d’entrée obligatoires pour activer CMK sur le serveur flexible cible.
Si l’instance serveur unique a activé le chiffrement double d’infrastructure, l’activation de la clé gérée par le client (CMK) sur l’instance de serveur flexible cible est recommandée pour prendre en charge des fonctionnalités similaires. Vous pouvez également choisir d’activer CMK sur le serveur cible avec des paramètres d’entrée de l’interface CLI d’importation Azure Database pour MySQL ou de post-migration.
Si « Magasin des requêtes » est activé sur l’instance de serveur unique, l’activation des journaux de requêtes lents sur l’instance de serveur flexible cible est recommandée pour prendre en charge des fonctionnalités similaires. Vous pouvez configurer les journaux de requêtes lentes sur le serveur flexible cible en suivant les étapes indiquées ici. Vous pouvez ensuite afficher des aperçus de requête à l’aide d’un modèle de classeurs.
Considérations importantes lors de l’utilisation du Réseau virtuel (VNet) et de l’interface CLI d’importation Azure Database pour MySQL : - Éviter les opérations simultanées sur le réseau virtuel : Lorsque vous exécutez une opération d’importation, évitez d’effectuer d’autres opérations sur le même réseau virtuel. Si d’autres opérations sont en cours, attendez qu’elles soient entièrement terminées avant de commencer l’opération d’importation. Cela permet d’éviter tout conflit potentiel ou conflit de ressources. - Limiter les migrations simultanées de serveurs : Si vous envisagez de migrer plusieurs serveurs qui résident sous le même réseau virtuel, n’initiez pas ces migrations en même temps. Cela pourrait entraîner le blocage des opérations dans le réseau virtuel, entraînant des délais d’attente allongés et même des expirations.
Si votre instance serveur unique a une architecture de stockage hérité (stockage d’usage général V1), vous devez définir le paramètre log_bin=ON pour votre instance de serveur unique avant de lancer l’opération d’importation. Pour ce faire, créez un réplica en lecture pour votre instance de serveur unique, puis supprimez-le. Cette opération définit le paramètre log_bin sur ON et vous pouvez ensuite déclencher une opération d’importation pour migrer vers un serveur flexible.
Si votre instance serveur unique a activé Advanced Threat Protection, vous devez activer Advanced Threat Protection sur l’instance de serveur flexible migrée après la migration en suivant les étapes [ici] (/azure/mysql/flexible-server/advanced-threat-protection-setting?view=azure-cli-latest).
Si votre instance de serveur unique a la version v8.0 du moteur, effectuez les actions suivantes pour éviter tout changement cassant dû à des différences de version mineure de la communauté entre l’instance de serveur unique et l’instance de serveur flexible :
Exécutez l’instruction suivante pour vérifier si votre instance peut être affectée par des informations d’histogramme erronées. Si les tables correspondantes sont générées en sortie, nous vous recommandons de vous référer à https://dev.mysql.com/blog-archive/histogram-statistics-in-mysql/ pour supprimer les informations d’histogramme, puis de les recréer sur le serveur flexible. Il convient de noter que les informations d’histogramme ne sont que des informations statistiques sur les colonnes, et qu’elles existent uniquement dans les tables système. Par conséquent, la suppression des informations d’histogramme n’affecte pas les données de table.
SELECT DISTINCT SCHEMA_NAME, TABLE_NAME FROM `information_schema`.`column_statistics`;Exécutez la commande suivante pour rechercher les tables dont l’ordre des colonnes de table est susceptible d’être désorganisé. Si cette vérification identifie des tables affectées, vous devez vider toutes les données de ces tables, puis les réimporter. Si vous ne le faites pas, la séquence de colonnes dans le binlog risque de ne pas correspondre à la séquence de colonnes dans les tables utilisateur. Cette non-correspondance peut empêcher les utilisateurs de configurer la réplication, de restaurer des données, d’activer la haute disponibilité, et d’effectuer autres opérations.
SELECT table_schema, table_name, COUNT(*) AS column_count, MAX(ORDINAL_POSITION) AS max_ordinal_position FROM information_schema.columns GROUP BY table_schema, table_name HAVING column_count != max_ordinal_position;
Seule l’importation de niveau instance est prise en charge. Aucune option permettant d’importer des bases de données sélectionnées au sein d’une instance n’est fournie.
Les éléments ci-dessous doivent être copiés depuis la source vers la cible par l’utilisateur après l’opération d’importation :
- Réplicas en lecture
- Paramètres de la page d’analyse (paramètres d’alertes, de métriques et de diagnostic)
- Tous les scripts Terraform/CLI que vous hébergez pour manager votre instance de serveur unique doivent être mis à jour avec les références du serveur flexible
Déclencher une opération d’importation Azure Database pour MySQL pour migrer d’un serveur unique vers un serveur flexible Azure Database pour MySQL
Déclenchez une opération d’importation Azure Database pour MySQL à l’aide de la commande az mysql flexible-server import create. La commande suivante crée un serveur flexible cible et effectue une importation de niveau instance depuis la source vers la destination cible à l’aide des valeurs par défaut du service et des valeurs du contexte local d’Azure CLI :
az mysql flexible-server import create --data-source-type
--data-source
--resource-group
--name
[--sku-name]
[--tier]
[--version]
[--storage-size]
[--mode]
[--admin-password]
[--admin-user]
[--auto-scale-iops {Disabled, Enabled}]
[--backup-identity]
[--backup-key]
[--backup-retention]
[--database-name]
[--geo-redundant-backup {Disabled, Enabled}]
[--high-availability {Disabled, SameZone, ZoneRedundant}]
[--identity]
[--iops]
[--key]
[--location]
[--private-dns-zone]
[--public-access]
[--resource-group]
[--standby-zone]
[--storage-auto-grow {Disabled, Enabled}]
[--subnet]
[--subnet-prefixes]
[--tags]
[--vnet]
[--zone]
L’exemple suivant utilise les informations de la source de données du serveur unique nommé « test-single-server » et les informations du serveur flexible cible, crée un serveur flexible cible nommé test-flexible-server à l’emplacement westus (même emplacement que celui du serveur unique source), puis effectue une importation de la source vers la cible. La commande d’importation Azure Database MySQL mappe les propriétés niveau, version, nom de la référence SKU, taille de stockage, emplacement, sauvegarde géoredondante, accès public, étiquettes, croissance automatique, jours de conservation des sauvegardes, utilisateur administrateur et mot de passe administrateur correspondantes du serveur unique au serveur flexible en tant que valeurs par défaut intelligentes si aucune entrée n’est fournie à la commande CLI. Vous pouvez choisir de remplacer les valeurs par défaut intelligentes en fournissant des entrées pour ces paramètres facultatifs.
az mysql flexible-server import create --data-source-type "mysql_single" --data-source "test-single-server" --resource-group "test-rg" --name "test-flexible-server"
L’exemple suivant utilise les informations de la source de données du serveur unique nommé « test-single-server » et les informations du serveur flexible cible, crée un serveur flexible cible nommé test-flexible-server à l’emplacement westus (le même emplacement que celui du serveur unique source) avec la redondance de zone activée et l’intégration du réseau virtuel, puis effectue une importation de la source vers la cible. Pour en savoir plus sur la configuration du réseau virtuel, cliquez ici.
# create vnet
az network vnet create --resource-group testGroup --name myVnet --location testLocation --address-prefixes 172.0.0.0/16
# create subnet
az network vnet subnet create --resource-group testGroup --vnet-name myVnet --address-prefixes 172.0.0.0/24 --name mySubnet
# create private dns zone
az network private-dns zone create -g testGroup -n myserver.private.contoso.com
# trigger mysql import
az mysql flexible-server import create --data-source-type "mysql_single" --data-source "test-single-server" --resource-group "test-rg" --name "test-flexible-server" --high-availability ZoneRedundant --zone 1 --standby-zone 3 --vnet "myVnet" --subnet "mySubnet" --private-dns-zone "myserver.private.contoso.com"
L’exemple suivant utilise les informations de la source de données du serveur unique nommé « test-single-server » avec une clé gérée par le client (CMK) activée et les informations du serveur flexible cible. Il crée également un serveur flexible cible nommé test-flexible-server, puis effectue une importation de la source vers la cible. Pour les instances de serveur unique compatibles CMK, la commande d’importation Azure Database pour MySQL vous oblige à fournir des paramètres d’entrée obligatoires pour l’activation de CMK : --key keyIdentifierOfTestKey --identity testIdentity.
# create keyvault
az keyvault create -g testGroup -n testVault --location testLocation \
--enable-purge-protection true
# create key in keyvault and save its key identifier
keyIdentifier=$(az keyvault key create --name testKey -p software \
--vault-name testVault --query key.kid -o tsv)
# create identity and save its principalId
identityPrincipalId=$(az identity create -g testGroup --name testIdentity \
--location testLocation --query principalId -o tsv)
# add testIdentity as an access policy with key permissions 'Wrap Key', 'Unwrap Key', 'Get' and 'List' inside testVault
az keyvault set-policy -g testGroup -n testVault --object-id $identityPrincipalId \
--key-permissions wrapKey unwrapKey get list
# trigger azure database for mysql import for CMK enabled single server
az mysql flexible-server import create --data-source-type "mysql_single" --data-source "test-single-server" --resource-group "test-rg" --name "test-flexible-server" --key $keyIdentifier --identity testIdentity
Voici les détails des arguments ci-dessus :
| Paramètre | Exemple de valeur | Description |
|---|---|---|
| data-source-type | mysql_single | Le type de source de données qui sert de destination source pour déclencher l’importation Azure Database pour MySQL. Valeurs acceptées : [mysql_single]. Description des valeurs acceptées - mysql_single : serveur unique Azure Database pour MySQL. |
| data-source | test-single-server | Nom ou ID de ressource du serveur unique source Azure Database pour MySQL. |
| resource-group | test-rg | Nom du groupe de ressources Azure du serveur unique source Azure Database pour MySQL. |
| mode | Hors connexion | Le mode d’importation Azure Database pour MySQL. Valeurs acceptées : [Hors connexion] ; Valeur par défaut : Hors connexion. |
| location | westus | Emplacement Azure du serveur unique source Azure Database pour MySQL. |
| name | test-flexible-server | Entrez un nom unique pour votre serveur flexible cible Azure Database pour MySQL. Le nom de serveur ne peut contenir que des lettres minuscules, des chiffres et le caractère de trait d’union (-). Il doit inclure entre 3 et 63 caractères. Remarque : Ce serveur est déployé dans le même abonnement, le même groupe de ressources et la même région que la source. |
| admin-user | adminuser | Nom d’utilisateur de la connexion administrateur à votre serveur flexible cible Azure Database pour MySQL. Il ne peut pas être azure_superuser (superutilisateur_azure), admin, administrator (administrateur), root (racine), guest (invité) ni public. |
| admin-password | mot de passe | Mot de passe de l’utilisateur administrateur de votre serveur flexible cible Azure Database pour MySQL. Il doit contenir entre 8 et 128 caractères. Votre mot de passe doit contenir des caractères des trois des catégories suivantes : lettres majuscules anglaises, lettres minuscules anglaises, chiffres et caractères non alphanumériques. |
| sku-name | GP_Gen5_2 | Entrez le nom du niveau tarifaire et la configuration de calcul de votre serveur flexible cible Azure Database pour MySQL. Suit la convention {niveau tarifaire} {génération de calcul} {vCores} dans le raccourci. Pour plus d’informations, consultez les niveaux tarifaires. |
| Niveau | Expansible | Niveau de calcul du serveur flexible cible Azure Database pour MySQL. Valeurs acceptées : Burstable, GeneralPurpose, MemoryOptimized ; Valeur par défaut : Burstable. |
| public-access | 0.0.0.0 | Détermine l’accès public au serveur flexible cible Azure Database pour MySQL. Entrez une adresse IP ou une plage d’adresses IP à inclure dans la liste des adresses IP autorisées. Les adresses IP de la plage doivent être séparées par des tirets et ne doivent pas contenir d’espaces. Spécifier 0.0.0.0 permet un accès public à votre serveur à partir de toutes les ressources déployées dans Azure. Le définir sur « Aucun » définit le serveur en mode d’accès public, mais ne crée pas de règle de pare-feu. |
| réseau virtuel | myVnet | Nom ou ID d’un réseau virtuel nouveau ou existant. Si vous voulez utiliser un réseau virtuel d’un groupe de ressources ou d’un abonnement différent, fournissez un ID de ressource. Le nom doit avoir entre 2 et 64 caractères. Le nom doit commencer par une lettre ou un chiffre et se terminer par une lettre, un chiffre ou un trait de soulignement, et il ne peut contenir que des lettres, des chiffres, des traits de soulignement, des points ou des traits d’union. |
| subnet | mySubnet | Nom ou ID de ressource d’un sous-réseau nouveau ou existant. Si vous voulez utiliser un sous-réseau d’un groupe de ressources ou d’un abonnement différent, fournissez un ID de ressource à la place du nom. Le sous-réseau sera délégué à flexibleServers. Après la délégation, ce sous-réseau ne peut être utilisé pour aucun autre type de ressources Azure. |
| private-dns-zone | myserver.private.contoso.com | Nom ou ID d’une zone DNS privée nouvelle ou existante. Vous pouvez utiliser la zone DNS privée du même groupe de ressources, d’un groupe de ressources différent ou d’un abonnement différent. Si vous voulez utiliser une zone d’un groupe de ressources ou d’un abonnement différent, veuillez fournir un ID de ressource. L’interface CLI crée une zone DNS privée dans le même groupe de ressources que le réseau virtuel si aucun n’est fourni par les utilisateurs. |
| key | identificateur de clé de testKey | ID de ressource de la clé de coffre de clés primaire pour le chiffrement des données. |
| identity | testIdentity | Nom ou ID de ressource de l’identité affectée par l’utilisateur pour le chiffrement des données. |
| storage-size | 32 | Capacité de stockage du serveur flexible cible Azure Database pour MySQL. La capacité minimale est de 20 Gio et la maximale de 16 Tio. |
| tags | key=value | Indiquez le nom du groupe de ressources Azure. |
| version | 5.7 | Version principale du serveur flexible cible Azure Database pour MySQL. |
| haute disponibilité | ZoneRedundant | Activez (ZoneRedundant ou SameZone) ou désactivez la fonctionnalité de haute disponibilité du serveur flexible cible Azure Database pour MySQL. Valeurs acceptées : Désactivée, SameZone, ZoneRedundant; Valeur par défaut : Désactivée. |
| zone | 1 | Zone de disponibilité dans laquelle approvisionner la ressource. |
| standby-zone | 3 | Informations de la zone de disponibilité du serveur de secours lorsqu’une haute disponibilité est activée. |
| storage-auto-grow | activé | Activez ou désactivez la croissance automatique du stockage du serveur flexible Azure Database pour MySQL. La valeur par défaut est : Activé. Valeurs acceptées : Désactivé, Activé ; Valeur par défaut : Activé. |
| iops | 500 | Nombre d’IOPS à allouer au serveur flexible cible Azure Database pour MySQL. Vous bénéficiez d’un certain nombre d’IOPS gratuites selon le calcul et le stockage approvisionnés. La valeur par défaut des IOPS est : IOPS libres. Pour en savoir plus sur les IOPS basées sur le calcul et le stockage, consultez IOPS dans une serveur flexible Azure Database pour MySQL. |
Étapes pour la migration en ligne
Après avoir terminé l’opération d’importation Azure Database pour MySQL mentionnée ci-dessus :
- Connectez-vous au serveur flexible Azure Database pour MySQL cible et exécutez la commande suivante pour obtenir le nom de fichier journal bin et la position correspondant à l’instantané de sauvegarde utilisé par l’interface CLI d’importation Azure Database pour MySQL pour restaurer sur le serveur cible.
CALL mysql.az_show_binlog_file_and_pos_for_mysql_import();
- Configurez la réplication des données entre les instances de serveur source et cible à l’aide de la position du journal bin en suivant les étapes répertoriées ici et lorsque l’état de réplication reflète que le serveur cible a rattrapé la source, arrêtez la réplication et effectuez le basculement.
Meilleures pratiques de configuration des paramètres de la commande CLI d’importation Azure Database pour MySQL
Avant de déclencher la commande de l’interface CLI d’importation Azure Database pour MySQL, tenez compte des conseils suivants de configuration des paramètres pour vous bénéficier de chargements de données plus rapides à l’aide de l’interface CLI d’importation Azure Database pour MySQL.
Si vous voulez remplacer les valeurs par défaut intelligentes, sélectionnez le niveau de calcul et le nom de la référence SKU du serveur flexible cible en fonction du niveau tarifaire et des VCores du serveur unique source, en vous basant sur les informations du tableau suivant.
Niveau tarifaire du serveur unique VCores du serveur unique Niveau du serveur flexible Nom SKU du serveur flexible De base 1 Expansible Standard_B2ms De base 2 Expansible Standard_B2ms Usage général 4 GeneralPurpose Standard_D4ds_v4 Usage général 8 GeneralPurpose Standard_D8ds_v4 Usage général 16 GeneralPurpose Standard_D16ds_v4 Usage général 32 GeneralPurpose Standard_D32ds_v4 Usage général 64 GeneralPurpose Standard_D64ds_v4 Mémoire optimisée 4 MemoryOptimized Standard_E4ds_v4 Mémoire optimisée 8 MemoryOptimized Standard_E8ds_v4 Mémoire optimisée 16 MemoryOptimized Standard_E16ds_v4 Mémoire optimisée 32 MemoryOptimized Standard_E32ds_v4 La version MySQL, la région l’abonnement et la ressource du serveur flexible cible doivent être les mêmes que ceux du serveur unique source.
La taille de stockage du serveur flexible cible doit être égale ou supérieure à celle du serveur unique source.
Si l’instance serveur unique a activé le chiffrement double d’infrastructure, l’activation de la clé gérée par le client (CMK) sur l’instance de serveur flexible cible est recommandée pour prendre en charge des fonctionnalités similaires. Vous pouvez également choisir d’activer CMK sur le serveur cible avec des paramètres d’entrée de l’interface CLI d’importation Azure Database pour MySQL ou de post-migration.
Combien de temps l’importation Azure Database pour MySQL prend-elle pour migrer mon instance de serveur unique ?
Vous trouverez ci-dessous les performances de référence en fonction de la taille de stockage pour l’architecture de stockage V2 à usage général. (Les serveurs dotés d’un stockage V1 à usage général prennent plus de temps pour migrer, car il implique également la mise à niveau de l’architecture de stockage)
| Taille de stockage du serveur unique | Durée d’importation |
|---|---|
| 1 Gio | 0 min 23 s |
| 10 Gio | 4 min 24 s |
| 100 Gio | 10 min 29 s |
| 500 Go | 13 min 15 s |
| 1 To | 22 min 56 s |
| 10 To | 2 h 5 min 30 s |
D'après le tableau ci-dessus, à mesure que la taille de stockage augmente, le temps nécessaire à la copie des données augmente également, presque dans une relation linéaire. Toutefois, il est important de noter que la vitesse de copie peut être considérablement affectée par les fluctuations du réseau. Par conséquent, les données fournies ici doivent être prises comme référence uniquement.
Vous trouverez ci-dessous les performances de référence basées sur un nombre variable de tables pour une taille de stockage de 10 Gio.
| Nombre de tables dans les instance de serveur unique | Durée d’importation |
|---|---|
| 100 | 4 min 24 s |
| 200 | 4 min 40 s |
| 800 | 4 min 52 s |
| 14 400 | 17 min 41 s |
| 28 800 | 19 min 18 s |
| 38 400 | 22 min 50 s |
À mesure que le nombre de fichiers augmente, chaque fichier/table de la base de données peut devenir très petit. Cela entraîne le transfert d’une quantité cohérente de données, mais il y aura des opérations liées aux fichiers plus fréquentes, ce qui peut avoir un impact sur les performances de l’importation Azure Database pour MySQL.
Étapes après importation
- Copiez les propriétés suivantes du serveur unique source vers le serveur flexible cible après que l’opération d’importation Azure Database pour MySQL se termine avec succès :
- Réplicas en lecture
- Valeur du paramètre de serveur pour event_scheduler
- Paramètres de la page d’analyse (paramètres d’alertes, de métriques et de diagnostic)
- Tous les scripts Terraform/CLI que vous hébergez pour manager votre instance de serveur unique doivent être mis à jour avec les références du serveur flexible.