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.
Les limites connues d'utilisation d'une base de données MySQL en tant que source incluent les suivantes:
La migration vers MySQL 5.6 ou MySQL 8.4 à l'aide d'un fichier de sauvegarde physique Percona XtraBackup n'est pas prise en charge.
Lorsque vous effectuez une migration entre les principales versions de MySQL (par exemple, de MySQL 8.0 vers MySQL 8.4), vous devez résoudre les incompatibilités potentielles pour assurer 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 corriger.
N'effectuez aucune modification LDD (langage de définition de données), telle que la modification des définitions de table, pendant la phase de vidage complet des données. Les modifications DDL effectuées avant que la tâche de migration ne passe à la phase CDC peuvent entraîner l'échec de la tâche 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 de droits SUPERUSER, des étapes supplémentaires sont requises pour réussir la migration, y compris un bref temps d'arrêt d'écriture sur la source. Pour en savoir plus, consultez les sections Spécifique à Amazon RDS et Spécifique à Amazon Aurora.
Le service de migration de base de données ne peut pas migrer les données d'une instance de réplication 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 lors de la migration du serveur, ce qui signifie que les informations sur les rôles utilisateur ne sont pas incluses.
Vous ne pouvez pas sélectionner d'objets de base de données spécifiques (tels que des bases de données, des tables ou des schémas) lorsque vous effectuez une migration à l'aide de Database Migration Service. Toutes les tables de toutes les bases de données et de tous les schémas sont migrées, à 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 de ces schémas. Sinon, votre migration peut échouer avec le messageERROR 1109 (42S02): Unknown table in <schema name here>. 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 si 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 permet de migrer des 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 pages Chiffrer les ressources Amazon Aurora et Chiffrer les ressources Amazon RDS.
Lors de la migration, la base de données Cloud SQL de destination est en mode lecture seule pour éviter toute modification de la base de données qui pourrait interrompre le processus de migration ou l'intégrité des données. Une fois la destination promue, elle devient accessible en écriture.
À l'heure actuelle, 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 limitation pour les formats
STATEMENTouMIXEDSi vous créez une tâche de migration continue à l'aide de votre propre fichier de vidage, n'utilisez pas l'utilitaire
mysqldumpà partir de la version 5.7.36 de MySQL. Pour en savoir plus, consultez le bug 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.
Remarques concernant le parallélisme du vidage des données
Le parallélisme de vidage de 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 de vidage de données, tenez compte des points suivants:
Le parallélisme de vidage de 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 de données, Database Migration Service verrouille brièvement votre base de données source, ce qui la rend temporairement indisponible pour les écritures. La durée du verrouillage dépend du nombre de tables dans la base de données source:
Nombre de tables Heure de verrouillage approximative 100 1 seconde 10K 9 secondes 50K 49 secondes
Limites des migrations vers des instances de destination existantes
- Votre instance de destination existante doit être vide ou ne contenir que des données de configuration système. La migration vers des instances de destination existantes contenant des données utilisateur (telles que des tables) n'est pas prise en charge.
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 la tâche de migration. Consultez la section Effacer les données supplémentaires de votre instance de destination existante.
- Vous ne pouvez configurer qu'une seule tâche de migration par instance de destination.
- Vous ne pouvez migrer que vers des instances Cloud SQL autonomes. La migration vers des répliques de serveurs externes n'est pas prise en charge.
- La migration de données vers une instance Cloud SQL sur laquelle Private Service Connect est activé n'est pas acceptée.
- Pour migrer vers une instance Cloud SQL dotée d'une instance répliquée avec accès en lecture, vous devez activer la journalisation des GTID (identifiants de transaction globaux) sur votre instance source.
- 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 des différences 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, vous pouvez supprimer des profils de connexion et des tâches de migration (y compris celles déjà effectuées).