Présentation
Avant de choisir de migrer vos bases de données vers Cloud SQL, assurez-vous de prendre en compte les limites connues pour 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 avec un fichier de sauvegarde physique Percona XtraBackup n'est pas prise en charge.
Lorsque vous migrez d'une version majeure de MySQL vers une autre (par exemple, de MySQL 8.0 vers MySQL 8.4), vous devez résoudre les éventuelles incompatibilités pour assurer une migration fluide sans problème de cohérence des données.
Lorsque 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'apportez aucune modification LDD (langage de définition de données), comme la modification des définitions de table, pendant la phase de vidage complet des données. Les modifications LDD effectuées avant que la tâche de migration ne passe à la phase CDC peuvent entraîner l'échec de votre tâche de migration. Pour en savoir plus, consultez 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 nécessaires pour que la migration réussisse, y compris un bref temps d'arrêt d'écriture sur la source. Pour en savoir plus, consultez les sections Amazon RDS et Amazon Aurora.
Database Migration Service ne peut pas migrer de données à partir d'une instance répliquée avec accès en lecture Amazon Aurora d'un cluster de bases de données MySQL, car il est impossible de récupérer les fichiers journaux binaires à 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 dans ces schémas. Sinon, votre migration peut échouer et le messageERROR 1109 (42S02): Unknown table in <schema name here>s'afficher. 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 Chiffrer les ressources Amazon Aurora et Chiffrer les ressources Amazon RDS.
Pendant 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 perturber le processus de migration ou l'intégrité des données. Une fois la destination promue, elle devient accessible en écriture.
Database Migration Service n'est actuellement 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, en utilisant l'instructionLOAD DATA IN FILE.En savoir plus sur cette limite pour les formats
STATEMENTouMIXEDSi 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.
Points à prendre en compte concernant le parallélisme du vidage des données
Le parallélisme de vidage des données vous permet de migrer depuis des 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 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 MySQL versions 5.7 ou 8.
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 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 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 répliquées de serveur externe n'est pas possible.
- 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, l'enregistrement des identifiants de transaction globaux (GTID) doit être activé 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 paramètres d'instance de destination différents de 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).