Configurer votre base de données MySQL source pour les migrations ponctuelles

Cette page explique comment configurer les instances de base de données sources suivantes pour des migrations MySQL homogènes ponctuelles :

Configurer une source Cloud SQL pour MySQL

Pour configurer une instance source Cloud SQL pour MySQL pour votre processus de migration, procédez comme suit :

  1. Vérifiez si votre base de données source contient des métadonnées définies par les utilisateurs avec la clause DEFINER. Consultez Vérifier les métadonnées avec une clause DEFINER.

    Database Migration Service pour les migrations MySQL homogènes ne migre pas les comptes utilisateur ni les connexions. Les sources contenant des métadonnées définies par des comptes utilisateur avec la clause DEFINER peuvent bloquer votre migration.

  2. Si votre base de données source contient des objets qui font référence à des tables dans les schémas système mysql, performance_schema, information_schema, ndbinfo ou sys, assurez-vous que les bases de données d'instance répliquée contiennent également ces tables de schéma système.

    Si les bases de données d'instance répliquée ne contiennent pas ces tables, votre job de migration peut échouer avec l'erreur Unknown table in system schema .

  3. Créez un compte utilisateur dédié à la migration dans votre instance. Consultez Créer un utilisateur dans la documentation Cloud SQL. Vérifiez les points suivants :

    • Vous autorisez le compte utilisateur dédié à se connecter depuis n'importe quel hôte (host=%).
    • Le mot de passe du compte ne dépasse pas 32 caractères. Pour en savoir plus sur les limites de longueur des mots de passe des utilisateurs MySQL, consultez le bug MySQL 43439.

  4. Attribuez les droits nécessaires au compte utilisateur dédié à la migration. Pour les migrations ponctuelles, la liste complète des droits requis dépend de l'utilisation de vos propres fichiers de dump ou de la fonctionnalité de dump gérée de Database Migration Service :

    Dump géré

    Si vous souhaitez que Database Migration Service effectue automatiquement le vidage complet de votre base de données source, attribuez les droits suivants au compte utilisateur :

    • SELECT
    • SHOW VIEW
    • TRIGGER
    • RELOAD
    • Pour les versions MySQL 8.0 ou ultérieures de la source : assurez-vous que le compte de migration ne dispose pas du droit BACKUP_ADMIN.

    Dump manuel

    Si vous fournissez vos propres fichiers de dump créés avec mysqldump, vous n'avez pas besoin d'attribuer de droits supplémentaires au compte utilisateur.

Configurer une source MySQL auto-hébergée

Pour configurer une instance source MySQL auto-hébergée pour votre processus de migration, procédez comme suit :

  1. Assurez-vous que toutes vos tables (à l'exception des tables des bases de données système) utilisent le moteur de stockage InnoDB. Si vous utilisez un autre moteur de stockage, vous devrez peut-être convertir vos tables. Pour en savoir plus, consultez Convertir des tables MyISAM vers InnoDB.
  2. Vérifiez si votre base de données source contient des métadonnées définies par les utilisateurs avec la clause DEFINER. Consultez Vérifier les métadonnées avec une clause DEFINER.

    Database Migration Service pour les migrations MySQL homogènes ne migre pas les comptes utilisateur ni les connexions. Les sources contenant des métadonnées définies par des comptes utilisateur avec la clause DEFINER peuvent bloquer votre migration.

  3. Si votre base de données source contient des objets qui font référence à des tables dans les schémas système mysql, performance_schema, information_schema, ndbinfo ou sys, assurez-vous que les bases de données d'instance répliquée contiennent également ces tables de schéma système.

    Si les bases de données d'instance répliquée ne contiennent pas ces tables, votre job de migration peut échouer avec l'erreur Unknown table in system schema .

  4. Assurez-vous que GTID_MODE est défini sur ON ou OFF. Aucune autre valeur n'est acceptée.

    Database Migration Service nécessite que GTID_MODE soit défini sur ON dans les scénarios suivants :

    Pour en savoir plus sur GTID_MODE, consultez Variable système d'ID de transaction globale.

  5. Créez un compte utilisateur dédié à la migration dans votre instance. Consultez Instructions de gestion des comptes. Vérifiez les points suivants :

    • Vous autorisez le compte utilisateur dédié à se connecter depuis n'importe quel hôte (host=%).
    • Le mot de passe du compte ne dépasse pas 32 caractères. Pour en savoir plus sur les limites de longueur des mots de passe des utilisateurs MySQL, consultez le bug MySQL 43439.

  6. Attribuez les droits nécessaires au compte utilisateur dédié à la migration. Pour les migrations ponctuelles, la liste complète des droits requis dépend de l'utilisation de vos propres fichiers de dump ou de la fonctionnalité de dump gérée de Database Migration Service :

    Dump géré

    Si vous souhaitez que Database Migration Service effectue automatiquement le vidage complet de votre base de données source, attribuez les droits suivants au compte utilisateur :

    Dump manuel

    Si vous fournissez vos propres fichiers de dump créés avec mysqldump, vous n'avez pas besoin d'attribuer de droits supplémentaires au compte utilisateur.

Configurer une source Amazon RDS pour MySQL

Pour configurer une instance source Amazon RDS pour MySQL pour votre processus de migration, procédez comme suit :

  1. Amazon RDS pour MySQL utilise le moteur de stockage InnoDB par défaut, mais permet d'utiliser d'autres moteurs de stockage. Assurez-vous que toutes vos tables (à l'exception des tables des bases de données système) utilisent le moteur de stockage InnoDB. Si vous utilisez un autre moteur de stockage, vous devrez peut-être convertir vos tables. Pour en savoir plus, consultez Convertir des tables MyISAM vers InnoDB.
  2. Vérifiez si votre base de données source contient des métadonnées définies par les utilisateurs avec la clause DEFINER. Consultez Vérifier les métadonnées avec une clause DEFINER.

    Database Migration Service pour les migrations MySQL homogènes ne migre pas les comptes utilisateur ni les connexions. Les sources contenant des métadonnées définies par des comptes utilisateur avec la clause DEFINER peuvent bloquer votre migration.

  3. Si votre base de données source contient des objets qui font référence à des tables dans les schémas système mysql, performance_schema, information_schema, ndbinfo ou sys, assurez-vous que les bases de données d'instance répliquée contiennent également ces tables de schéma système.

    Si les bases de données d'instance répliquée ne contiennent pas ces tables, votre job de migration peut échouer avec l'erreur Unknown table in system schema .

  4. Assurez-vous que GTID_MODE est défini sur ON ou OFF. Aucune autre valeur n'est acceptée. Amazon RDS pour MySQL utilise GTID_MODE = OFF par défaut.

    Database Migration Service nécessite que GTID_MODE soit défini sur ON dans les scénarios suivants :

    Pour en savoir plus sur GTID_MODE, consultez Variable système d'ID de transaction globale.

  5. Créez un compte utilisateur dédié à la migration dans votre instance. Consultez Instructions de gestion des comptes. Vérifiez les points suivants :

    • Vous autorisez le compte utilisateur dédié à se connecter depuis n'importe quel hôte (host=%).
    • Le mot de passe du compte ne dépasse pas 32 caractères. Pour en savoir plus sur les limites de longueur des mots de passe des utilisateurs MySQL, consultez le bug MySQL 43439.

  6. Attribuez les droits nécessaires au compte utilisateur dédié à la migration. Pour les migrations ponctuelles, la liste complète des droits requis dépend de l'utilisation de vos propres fichiers de dump ou de la fonctionnalité de dump gérée de Database Migration Service :

    Dump géré

    Si vous souhaitez que Database Migration Service effectue automatiquement le vidage complet de votre base de données source, attribuez les droits suivants au compte utilisateur :

    Dump manuel

    Si vous fournissez vos propres fichiers de dump créés avec mysqldump, vous n'avez pas besoin d'attribuer de droits supplémentaires au compte utilisateur.

Configurer une source Amazon Aurora pour MySQL

Pour configurer une instance source Amazon Aurora pour MySQL pour votre processus de migration, procédez comme suit :

  1. Vérifiez si votre base de données source contient des métadonnées définies par les utilisateurs avec la clause DEFINER. Consultez Vérifier les métadonnées avec une clause DEFINER.

    Database Migration Service pour les migrations MySQL homogènes ne migre pas les comptes utilisateur ni les connexions. Les sources contenant des métadonnées définies par des comptes utilisateur avec la clause DEFINER peuvent bloquer votre migration.

  2. Si votre base de données source contient des objets qui font référence à des tables dans les schémas système mysql, performance_schema, information_schema, ndbinfo ou sys, assurez-vous que les bases de données d'instance répliquée contiennent également ces tables de schéma système.

    Si les bases de données d'instance répliquée ne contiennent pas ces tables, votre job de migration peut échouer avec l'erreur Unknown table in system schema .

  3. Assurez-vous que GTID_MODE est défini sur ON ou OFF. Aucune autre valeur n'est acceptée. Amazon Aurora pour MySQL utilise GTID_MODE = OFF par défaut.

    Database Migration Service nécessite que GTID_MODE soit défini sur ON dans les scénarios suivants :

    Pour en savoir plus sur GTID_MODE, consultez Variable système d'ID de transaction globale.

  4. Créez un compte utilisateur dédié à la migration dans votre instance. Consultez Instructions de gestion des comptes. Vérifiez les points suivants :

    • Vous autorisez le compte utilisateur dédié à se connecter depuis n'importe quel hôte (host=%).
    • Le mot de passe du compte ne dépasse pas 32 caractères. Pour en savoir plus sur les limites de longueur des mots de passe des utilisateurs MySQL, consultez le bug MySQL 43439.

  5. Attribuez les droits nécessaires au compte utilisateur dédié à la migration. Pour les migrations ponctuelles, la liste complète des droits requis dépend de l'utilisation de vos propres fichiers de dump ou de la fonctionnalité de dump gérée de Database Migration Service :

    Dump géré

    Si vous souhaitez que Database Migration Service effectue automatiquement le vidage complet de votre base de données source, attribuez les droits suivants au compte utilisateur :

    Dump manuel

    Si vous fournissez vos propres fichiers de dump créés avec mysqldump, vous n'avez pas besoin d'attribuer de droits supplémentaires au compte utilisateur.

Configurer une source Microsoft Azure Database pour MySQL

Pour configurer une instance source Microsoft Azure Database pour MySQL pour votre processus de migration, procédez comme suit :

  1. Vérifiez si votre base de données source contient des métadonnées définies par les utilisateurs avec la clause DEFINER. Consultez Vérifier les métadonnées avec une clause DEFINER.

    Database Migration Service pour les migrations MySQL homogènes ne migre pas les comptes utilisateur ni les connexions. Les sources contenant des métadonnées définies par des comptes utilisateur avec la clause DEFINER peuvent bloquer votre migration.

  2. Si votre base de données source contient des objets qui font référence à des tables dans les schémas système mysql, performance_schema, information_schema, ndbinfo ou sys, assurez-vous que les bases de données d'instance répliquée contiennent également ces tables de schéma système.

    Si les bases de données d'instance répliquée ne contiennent pas ces tables, votre job de migration peut échouer avec l'erreur Unknown table in system schema .

  3. Assurez-vous que GTID_MODE est défini sur ON ou OFF. Aucune autre valeur n'est acceptée. Microsoft Azure Database pour MySQL utilise GTID_MODE = OFF par défaut.

    Database Migration Service nécessite que GTID_MODE soit défini sur ON dans les scénarios suivants :

    Pour en savoir plus sur GTID_MODE, consultez Variable système d'ID de transaction globale.

  4. Vérifiez la valeur de votre paramètre require_secure_transport.

    Par défaut, les bases de données Microsoft Azure nécessitent un chiffrement SSL/TLS pour toutes les connexions entrantes. En fonction de la valeur require_secure_transport, utilisez l'un des paramètres de chiffrement suivants lorsque vous créez le profil de connexion source :

    • Si require_secure_transport est défini sur on, sélectionnez Basic, TLS ou mTLS.
    • Si require_secure_transport est défini sur off, sélectionnez Aucun.

  5. Créez un compte utilisateur dédié à la migration dans votre instance. Consultez Instructions de gestion des comptes. Vérifiez les points suivants :

    • Vous autorisez le compte utilisateur dédié à se connecter depuis n'importe quel hôte (host=%).
    • Le mot de passe du compte ne dépasse pas 32 caractères. Pour en savoir plus sur les limites de longueur des mots de passe des utilisateurs MySQL, consultez le bug MySQL 43439.

  6. Attribuez les droits nécessaires au compte utilisateur dédié à la migration. Pour les migrations ponctuelles, la liste complète des droits requis dépend de l'utilisation de vos propres fichiers de dump ou de la fonctionnalité de dump gérée de Database Migration Service :

    Dump géré

    Si vous souhaitez que Database Migration Service effectue automatiquement le vidage complet de votre base de données source, attribuez les droits suivants au compte utilisateur :

    Dump manuel

    Si vous fournissez vos propres fichiers de dump créés avec mysqldump, vous n'avez pas besoin d'attribuer de droits supplémentaires au compte utilisateur.

Étapes suivantes

Pour obtenir un tutoriel de migration complet, étape par étape, pour les migrations Cloud SQL pour MySQL homogènes, consultez Premiers pas avec les migrations Cloud SQL pour MySQL.