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 dans la compatibilité des fonctionnalités. Consultez Découvrir et importer des bases de données dans la documentation de Migration Center.

Voici certaines des limitations connues affectant l'utilisation d'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 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 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 possible.

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

  • Le flag local_infile de votre base de données de destination doit être défini 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 concernées, telles que la page Configurer la base de données source.

• 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èmes 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.

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

• Pendant la phase de vidage complet des données, vous ne pouvez pas effectuer d'opérations 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'erreur Table definition has changed) ou l'arrêt de la réponse (et signaler des erreurs de délai avant 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 dans la section de 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 d'écriture sur la source. Pour en savoir plus, consultez les sections Configurer la base de données source pour Amazon RDS et Spécificités d'Amazon Aurora.

• Database Migration Service ne peut pas migrer les données d'une instance répliquée avec accès en lecture Amazon Aurora ou d'une instance répliquée avec accès en lecture MySQL Oracle Cloud Infrastructure (OCI), 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 spécifique à Amazon Aurora.

• Lors de la migration à partir d'une instance répliquée avec accès en lecture MySQL autogérée, le GTID n'est pas accepté. 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 lors de la migration du serveur. Par conséquent, les informations sur les comptes utilisateur, les connexions 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 d'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. Tous les objets et tables 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 faisant référence à des tables dans ces schémas. Sinon, votre migration peut échouer avec le message ERROR 1109 (42S02): Unknown table in <schema name here>. 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 pour empêcher toute modification de la base de données, ce 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, en utilisant l'instruction LOAD DATA IN FILE.

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

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

Remarques concernant le parallélisme du vidage des données

Le parallélisme des vidages de données vous permet de migrer 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 de données, tenez compte des points suivants :

• Le parallélisme de vidage de données n'est disponible que lors de la migration vers MySQL 5.7, 8.0, 8.4 ou 9.7.

• 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
  50 000	49 secondes

Remarque : Dans les cas où il n'est pas possible de verrouiller votre base de données source, utilisez plutôt une instance dupliquée avec accès en lecture comme base de données source. Pour en savoir plus sur la migration à partir d'instances répliqué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 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 possible.

  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 relancez 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.
• Pour migrer vers une instance Cloud SQL dotée d'une instance répliquée avec accès en lecture, la journalisation des identifiants de transaction globaux (GTID) doit être activée 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.
• 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 instructions 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.