Limites connues

Avant de choisir de migrer vos bases de données vers Cloud SQL, tenez compte des limites connues pour ce scénario de migration.

Remarque : Vous pouvez également utiliser Google Cloud Migration Center pour identifier les lacunes en termes de compatibilité des fonctionnalités. Consultez Découvrir et importer des bases de données dans la documentation Migration Center.

Voici certaines des limites connues lorsque vous utilisez une base de données MySQL comme source :

• Pour migrer des bases de données chiffrées, vous devez fournir les clés de chiffrement à Database Migration Service. Database Migration Service est compatible avec la migration de données depuis des 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 des ressources Amazon Aurora, Chiffrer des ressources Amazon RDS, et Configurer des clés de chiffrement gérées par le client (CMEK).

• La migration vers MySQL 5.6, MySQL 8.4 ou MySQL 9.7 avec un fichier de sauvegarde physique Percona XtraBackup n'est pas compatible.

• Pour les migrations de MySQL 8.0 vers MySQL 8.4 et de MySQL 8.4 vers MySQL 9.7 :

  • L'option local_infile de votre base de données de destination doit être définie sur ON.
  • Le compte de migration dédié sur l'instance source ne peut pas disposer du droit BACKUP_ADMIN.

  Ces considérations sont également abordées dans les sections correspondantes, telles que la page Configurer la base de données source.

• Lorsque vous effectuez une migration entre des versions majeures de MySQL (par exemple, de MySQL 8.0 à 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.

  • MySQL 9.7
  • MySQL 8.4
  • MySQL 8.0
  • MySQL 5.7

• Pendant la phase de vidage complet des données, vous ne pouvez effectuer aucune opération de langage de définition de données (LDD) (telles que ALTER TABLE, DROP TABLE, TRUNCATE TABLE) sur votre base de données source. L'exécution de ces opérations pendant la phase de vidage complet peut entraîner un blocage des métadonnées, ce qui peut provoquer l'échec du processus de migration (avec l' Table definition has changed erreur) ou l'arrêt de la réponse (et générer des erreurs de délai d'expiration telles que ERROR: While 'Loading data': Dump timeout ou MySQL Error 2013 (HY000): Lost connection to MySQL server during query). Vous pouvez effectuer des modifications LDD sur votre base de données source pendant la phase CDC. Pour en savoir plus, consultez les entrées suivantes de la section Dépannage :

  • Table definition has changed
  • While 'Loading data': dump timeout
  • MySQL Error 2013: Lost connection to MySQL server during query
  • Timeout waiting for no write traffic on the source: context deadline exceeded

• 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 réussir la migration, y compris un bref temps d'arrêt en écriture sur la source. Pour en savoir plus, consultez les sections Configurer la base de données source pour Amazon RDS et Configurer la base de données source pour Amazon Aurora.

• Database Migration Service ne peut pas migrer de données à partir d'une instance dupliquée avec accès en lecture Amazon Aurora ou d'une instance dupliquée avec accès en lecture Oracle Cloud Infrastructure (OCI) MySQL, car les fichiers journaux binaires ne peuvent pas être récupérés à partir de l'instance. Pour en savoir plus sur Amazon Aurora, consultez la section Configurer la base de données source pour Amazon Aurora.

• Lorsque vous effectuez une migration à partir d'une instance dupliquée avec accès en lecture MySQL autogérée, GTID n'est pas compatible. Vous devez utiliser la réplication basée sur le fichier journal binaire et la position. Pour en savoir plus, consultez Types et phases de migration.

• La base de données système MySQL n'est pas migrée dans le cadre de la migration du serveur. Par conséquent, les informations sur les comptes utilisateur, les identifiants et les rôles ne sont pas incluses.

• Bien que vous puissiez sélectionner des bases de données spécifiques à migrer, vous ne pouvez pas filtrer ni sélectionner des objets de base de données individuels dans une base de données (tels que des tables, des vues ou des procédures stockées spécifiques) lorsque vous effectuez une migration à l'aide de Database Migration Service. Toutes les tables et tous les objets InnoDB de chaque base de données sélectionnée sont migrés, à l'exception des schémas système suivants : mysql, performance_schema, information_schema et sys. 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 le ERROR 1109 (42S02): Unknown table in <schema name here> message. Consultez Configurer votre base de données source et Diagnostiquer les problèmes.

• 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 interrompre 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 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 que STATEMENT ou MIXED, la réplication peut échouer. Par exemple, à l'aide de l'instruction LOAD DATA IN FILE.

  En savoir plus sur cette limite pour les STATEMENT ou MIXED formats.

• Si vous créez un job de migration continue à l'aide de votre propre fichier de dump, n'utilisez pas l'utilitaire mysqldump 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.

• 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 de VPC.

Considérations sur le parallélisme du vidage des données

Le parallélisme du 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 du vidage des données, tenez compte des points suivants :

• Le parallélisme du vidage des données n'est disponible que lors de la migration vers les versions 5.7, 8.0, 8.4 ou 9.7 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

Remarque : Dans les scénarios où il n'est pas possible de verrouiller votre base de données source, utilisez une instance dupliquée avec accès en lecture comme base de données source. Pour savoir comment migrer à partir d'instances dupliquées avec accès en lecture dans Amazon RDS, consultez Migrer depuis RDS MySQL.

Limites des migrations vers des instances de destination existantes

• Votre instance de destination existante ne peut contenir que des 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 de l'ID de transaction global (GTID) sur votre instance source.
• Vous ne pouvez pas utiliser d'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, vous pouvez supprimer des jobs de migration (y compris ceux qui sont terminés) et des profils de connexion.