Présentation
Avant de choisir de migrer vos bases de données vers Cloud SQL, assurez-vous de prendre en compte les limites connues de ce scénario de migration.
Voici quelques limites connues liées à l'utilisation d'une base de données MySQL comme source :
La migration vers MySQL 5.6 ou MySQL 8.4 avec un fichier de sauvegarde physique Percona XtraBackup n'est pas compatible.
Pour les migrations de MySQL 8.0 vers MySQL 8.4 : voici quelques considérations supplémentaires pour les migrations 8.0 vers 8.4 :
- L'option
local_infilede votre base de données de destination doit être définie surON. - Le compte de migration dédié sur l'instance source ne peut pas disposer du
BACKUP_ADMINdroit.
Ces considérations sont également abordées dans les sections concernées, telles que la page Configurer la base de données source.
- L'option
Lorsque vous migrez entre des versions majeures de MySQL (par exemple, de MySQL 8.0 vers MySQL 8.4), vous devez résoudre les éventuelles incompatibilités pour garantir une migration fluide sans problème de cohérence des données.
Lorsque vous vous préparez à une migration entre versions, consultez les fonctionnalités compatibles avec Cloud SQL pour MySQL ainsi que les notes de version de votre version majeure cible pour déterminer les incompatibilités que vous devez résoudre.
N'apportez aucune modification au langage de définition de données (LDD), par exemple en modifiant les définitions de table, pendant la phase de vidage complet des données. Les modifications LDD effectuées avant que le job de migration ne passe à la phase CDC peuvent entraîner l'échec de votre job de migration. Pour en savoir plus, consultez la section Diagnostiquer les problèmes : erreur
Table definition has changed.Si la source est Amazon RDS MySQL, Amazon Aurora MySQL ou une source qui n'accorde pas les droits SUPERUSER, des étapes supplémentaires sont nécessaires pour réussir la migration, y compris un bref temps d'arrêt en écriture sur la source. Pour en savoir plus, consultez les sections spécifiques à Amazon RDS et spécifiques à Amazon Aurora.
Database Migration Service ne peut pas migrer les données d'une instance dupliquée avec accès en lecture Amazon Aurora d'un cluster de base de données MySQL, car les fichiers journaux binaires ne peuvent pas être récupérés à partir de l'instance. Pour en savoir plus, consultez la section spécifique à Amazon Aurora.
La base de données système MySQL n'est pas migrée dans le cadre de la migration du serveur, ce qui signifie que les informations sur les rôles utilisateur ne sont pas incluses.
Vous pouvez sélectionner des bases de données spécifiques lorsque vous migrez à l'aide de Database Migration Service. Toutes les tables et tous les schémas des bases de données sélectionnées sont migrés, à l'exception des schémas système suivants :
mysql,performance_schema,information_schemaetsys. Avant de commencer la migration, assurez-vous que votre base de données source ne contient pas d'objets qui font référence à des tables dans ces schémas. Sinon, votre migration peut échouer avec leERROR 1109 (42S02): Unknown table in <schema name here>message. Consultez Configurer votre base de données source et Diagnostiquer les problèmes.Si les bases de données chiffrées nécessitent des clés de chiffrement gérées par le client pour déchiffrer les informations qu'elles contiennent et que Database Migration Service n'a pas accès à ces clés, les bases de données ne peuvent pas être migrées.
Database Migration Service est compatible avec la migration de données à partir de bases de données Amazon Aurora ou Amazon RDS chiffrées, car ces bases de données gèrent le déchiffrement de manière transparente dans leurs services. Pour en savoir plus, consultez les sections Chiffrer des ressources Amazon Aurora et Chiffrer des ressources Amazon RDS.
Pendant la migration, la base de données Cloud SQL de destination est en mode lecture seule afin d'empêcher toute modification de la base de données qui pourrait perturber le processus de migration ou l'intégrité des données. Une fois la destination promue, elle devient accessible en écriture.
Actuellement, Database Migration Service n'est pas compatible avec MariaDB.
Vous devez définir le format du journal binaire sur
ROW. Si vous configurez le journal binaire dans un autre format, tel queSTATEMENTouMIXED, la réplication peut échouer. Par exemple, à l'aide de l'instructionLOAD DATA IN FILE.En savoir plus sur cette limite pour les formats
STATEMENTouMIXED.Si vous créez un job de migration continue à l'aide de votre propre fichier de dump, n'utilisez pas l'utilitaire
mysqldumpde MySQL version 5.7.36. Pour en savoir plus, consultez le bug n° 105761 dans la documentation MySQL.InnoDB est le seul moteur de stockage compatible avec Cloud SQL. La migration avec MyISAM peut entraîner des incohérences et nécessiter une validation des données. Pour obtenir de l'aide sur la conversion de tables MyISAM vers InnoDB, consultez la documentation MySQL.
La méthode de connectivité des interfaces Private Service Connect n'est compatible qu'avec la migration vers des instances de destination existantes. Si vous souhaitez utiliser la connectivité IP privée et migrer vers une nouvelle instance de destination, utilisez l'appairage VPC.
Considérations sur le parallélisme du vidage des données
Le parallélisme du vidage des données vous permet de migrer à partir de bases de données MySQL à l'aide d'un mécanisme de vidage hautes performances, ce qui améliore considérablement la vitesse de migration. Lorsque vous utilisez le parallélisme du vidage des données, tenez compte des points suivants :
Le parallélisme du vidage des données n'est actuellement disponible que lors de la migration vers les versions 5.7 ou 8 de MySQL.
Au début du vidage des données, Database Migration Service verrouille brièvement votre base de données source, ce qui la rend temporairement indisponible en écriture. La durée du verrouillage dépend du nombre de tables dans la base de données source :
Nombre de tables Durée approximative du verrouillage 100 1 seconde 10K 9 secondes 50K 49 secondes
Limites des migrations vers des instances de destination existantes
- Votre instance de destination existante ne peut contenir que les bases de données système par défaut
qui sont configurées automatiquement lorsque vous créez l'instance de destination.
La migration vers des instances de destination existantes
contenant des données utilisateur (telles que des tables dans des schémas système ou des bases de données)
n'est pas compatible.
Si vous rencontrez des problèmes en raison de données supplémentaires dans votre instance de destination existante, effacez les bases de données de votre instance de destination et réessayez le job de migration. Consultez Effacer les données supplémentaires de votre instance de destination existante.
- Vous ne pouvez configurer qu'un seul job de migration par instance de destination.
- Vous ne pouvez migrer que vers des instances Cloud SQL autonomes. La migration vers des instances dupliquées de serveur externe n'est pas compatible.
- Pour migrer vers une instance Cloud SQL disposant d'une instance dupliquée avec accès en lecture vous devez activer la journalisation des identifiants de transaction globaux (GTID) sur votre instance source.
- Vous ne pouvez pas utiliser les instances dupliquées avec accès en lecture Cloud SQL pour MySQL comme instance de destination de la migration instance.
- Pour les utilisateurs de Terraform : Database Migration Service modifie les paramètres de sauvegarde et de récupération de votre instance de destination. Cela peut entraîner une différence entre les paramètres de l'instance de destination et la configuration Terraform que vous avez utilisée pour le provisionnement. Si vous rencontrez ce problème, suivez les conseils de la section Diagnostiquer les problèmes.
Quotas
- Jusqu'à 2 000 profils de connexion et 1 000 tâches de migration peuvent coexister à un moment donné. Pour libérer de l'espace, supprimez des profils de connexion et des tâches de migration (y compris celles déjà effectuées).