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

Cette page explique comment configurer les instances de base de données source suivantes pour les 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 des utilisateurs avec la DEFINER clause. Consultez Vérifier les métadonnées avec une DEFINER clause.

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

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

    Si les bases de données répliquées ne contiennent pas ces tables, votre job de migration peut échouer avec le 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 utilisateur 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 du fait que vous fournissiez vos propres fichiers de dump ou que vous utilisiez la fonctionnalité de vidage géré de Database Migration Service :

    Vidage 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 source 8.0 ou ultérieures : assurez-vous que le compte de migration ne dispose pas du droit BACKUP_ADMIN.

    Vidage manuel

    Si vous fournissez vos propres fichiers de vidage 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 des utilisateurs avec la DEFINER clause. Consultez Vérifier les métadonnées avec une DEFINER clause.

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

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

    Si les bases de données répliquées ne contiennent pas ces tables, votre job de migration peut échouer avec le 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 cas 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 Déclarations 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 utilisateur 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 du fait que vous fournissiez vos propres fichiers de dump ou que vous utilisiez la fonctionnalité de vidage géré de Database Migration Service :

    Vidage 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 :

    Vidage manuel

    Si vous fournissez vos propres fichiers de vidage 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 autorise l'utilisation 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 des utilisateurs avec la DEFINER clause. Consultez Vérifier les métadonnées avec une DEFINER clause.

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

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

    Si les bases de données répliquées ne contiennent pas ces tables, votre job de migration peut échouer avec le 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 cas 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 Déclarations 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 utilisateur 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 du fait que vous fournissiez vos propres fichiers de dump ou que vous utilisiez la fonctionnalité de vidage géré de Database Migration Service :

    Vidage 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 :

    Vidage manuel

    Si vous fournissez vos propres fichiers de vidage 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 des utilisateurs avec la DEFINER clause. Consultez Vérifier les métadonnées avec une DEFINER clause.

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

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

    Si les bases de données répliquées ne contiennent pas ces tables, votre job de migration peut échouer avec le 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 cas 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 Déclarations 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 utilisateur 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 du fait que vous fournissiez vos propres fichiers de dump ou que vous utilisiez la fonctionnalité de vidage géré de Database Migration Service :

    Vidage 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 :

    Vidage manuel

    Si vous fournissez vos propres fichiers de vidage 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 des utilisateurs avec la DEFINER clause. Consultez Vérifier les métadonnées avec une DEFINER clause.

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

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

    Si les bases de données répliquées ne contiennent pas ces tables, votre job de migration peut échouer avec le 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 cas 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 le 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 (De base), TLS ou mTLS.
    • Si require_secure_transport est défini sur off, sélectionnez None (Aucun).

  5. Créez un compte utilisateur dédié à la migration dans votre instance. Consultez Déclarations 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 utilisateur 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 du fait que vous fournissiez vos propres fichiers de dump ou que vous utilisiez la fonctionnalité de vidage géré de Database Migration Service :

    Vidage 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 :

    Vidage manuel

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

Étape suivante

Pour obtenir une procédure de migration complète et détaillée pour les migrations Cloud SQL pour MySQL homogènes, consultez Premiers pas avec les migrations Cloud SQL pour MySQL.