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

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

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 répliquées 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. Activez et configurez les journaux binaires sur votre base de données source.

    Dans Cloud SQL pour MySQL, la journalisation binaire est activée automatiquement lorsque vous utilisez la récupération à un moment précis (PITR). Vous pouvez configurer le format des journaux et la période de conservation à l'aide des options système disponibles dans Cloud SQL. Procédez comme suit :

    1. Activez la récupération PITR sur votre instance. Cette fonctionnalité active automatiquement la journalisation binaire. Il n'est pas possible d'activer la journalisation binaire sans la récupération PITR dans Cloud SQL. Consultez la section Récupération à un moment précis (PITR) dans la documentation Cloud SQL.
    2. Utilisez les options Cloud SQL pour ajuster la configuration de la journalisation. Pour en savoir plus, consultez Configurer des indicateurs de base de données dans la documentation Cloud SQL.
      1. Database Migration Service nécessite que binlog_format soit défini sur ROW. Vous n'avez pas besoin d'ajuster ce paramètre. Cloud SQL pour MySQL définit automatiquement l'option binlog_format sur ROW.
      2. Définissez la durée de conservation des journaux sur une période suffisamment longue pour permettre la migration de la base de données. En général, une semaine suffit. Utilisez l'un des indicateurs suivants :
        • MySQL 5.6 - 5.7 : expire_logs_days
        • MySQL 8.0 et versions ultérieures : expire_logs_days, binlog_expire_logs_seconds

  4. 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 Bug MySQL #43439.

  5. Attribuez les droits nécessaires au compte utilisateur dédié à la migration. Pour les migrations continues, 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é 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 :

    Dump manuel

    Si vous fournissez vos propres fichiers de dump créés avec mysqldump, vous devez fournir les droits requis pour la phase CDC :

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 identifiants. 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 répliquées ne contiennent pas ces tables, votre tâche de migration peut échouer et afficher l'erreur Unknown table in system schema .

  4. Définissez le paramètre server-id sur une valeur supérieure ou égale à 1. Pour en savoir plus, consultez Options et variables de réplication et de journalisation binaire.

  5. 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.

  6. Activez et configurez les journaux binaires sur votre base de données source. Procédez comme suit :

  7. Créez un compte utilisateur dédié à la migration dans votre instance. Consultez Relevés de gestion de compte. 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 n° 43439.

  8. Attribuez les droits nécessaires au compte utilisateur dédié à la migration. Pour les migrations continues, la liste complète des droits d'accès requis dépend de si vous fournissez vos propres fichiers de vidage ou si vous utilisez 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 :

    Dump manuel

    Si vous fournissez vos propres fichiers de dump créés avec mysqldump, vous devez fournir les droits requis pour la phase CDC :

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'instances répliquées 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 "ID de transaction global".

  5. Vérifiez et configurez les journaux binaires sur votre base de données source. Procédez comme suit :

    1. Assurez-vous que votre instance utilise des sauvegardes automatiques. Amazon RDS ne génère des journaux binaires que lorsque les sauvegardes automatiques sont activées. Pour en savoir plus, consultez Activer les sauvegardes automatiques dans la documentation Amazon RDS.

    2. Définissez la période de conservation des journaux sur une durée suffisamment longue pour permettre la migration de la base de données. En général, une semaine suffit. Consultez Définir et afficher la configuration du journal binaire dans la documentation Amazon RDS.

    3. Redémarrez votre serveur pour que les modifications apportées soient prises en compte.

  6. Créez un compte utilisateur dédié à la migration dans votre instance. Consultez Relevés de gestion de compte. 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 n° 43439.

  7. Attribuez les droits nécessaires au compte utilisateur dédié à la migration. Pour les migrations continues, 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 :

    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 :

    Dump manuel

    Si vous fournissez vos propres fichiers de dump créés avec mysqldump, vous devez fournir les droits requis pour la phase CDC :

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 répliquées ne contiennent pas ces tables, votre tâche de migration peut échouer et afficher 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 "ID de transaction global".

  4. Activez et configurez les journaux binaires sur votre base de données source. Procédez comme suit :

    1. Activez la journalisation binaire pour votre base de données MySQL.

    2. Définissez la durée de conservation des journaux sur une période suffisamment longue pour permettre la migration de la base de données. En général, une semaine suffit. Consultez Définir et afficher la configuration du journal binaire.

    3. Redémarrez votre serveur pour que les modifications apportées soient prises en compte.

  5. Créez un compte utilisateur dédié à la migration dans votre instance. Consultez Relevés de gestion de compte. 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 Bug MySQL #43439.

  6. Attribuez les droits nécessaires au compte utilisateur dédié à la migration. Pour les migrations continues, 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é 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 :

    Dump manuel

    Si vous fournissez vos propres fichiers de dump créés avec mysqldump, vous devez fournir les droits requis pour la phase CDC :

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 identifiants. 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 et configurez les paramètres de journalisation binaire sur votre base de données source. Procédez comme suit :

    1. La journalisation binaire est activée par défaut sur Microsoft Azure Database pour MySQL. Vous n'avez pas besoin de l'activer, mais vérifiez qu'elle l'est. Pour en savoir plus, consultez la documentation Microsoft.

    2. Définissez binlog_expire_logs_seconds sur une période suffisamment longue pour permettre la migration de la base de données. En général, une semaine suffit.

      Pour en savoir plus, consultez Configurer les paramètres du serveur dans Azure Database pour MySQL et le paramètre binlog_expire_logs_seconds dans la documentation Microsoft.

    3. Redémarrez votre serveur pour que les modifications apportées soient prises en compte.

  5. 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.

  6. Créez un compte utilisateur dédié à la migration dans votre instance. Consultez Relevés de gestion de compte. 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 n° 43439.

  7. Attribuez les droits nécessaires au compte utilisateur dédié à la migration. Pour les migrations continues, la liste complète des droits d'accès requis dépend de si vous fournissez vos propres fichiers de vidage ou si vous utilisez 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 dump créés avec mysqldump, vous devez fournir les droits requis pour la phase CDC :

É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.