Lorsque vous créez et exécutez une tâche de migration avec une source MySQL Amazon Aurora ou des sources qui n'autorisent pas les droits SUPERUSER, la migration peut nécessiter des étapes supplémentaires.
Créer la tâche de migration MySQL Amazon Aurora
Tenez compte des exigences suivantes et ajustez votre processus de migration:
MySQL limite la définition du nom d'hôte source à 60 caractères. Les noms d'hôte des bases de données Amazon Aurora comptent généralement plus de 60 caractères. Si tel est le cas pour la base de données que vous migrez, configurez une redirection DNS pour créer un enregistrement CNAME qui associe votre nom de domaine au nom de domaine de votre instance de base de données Amazon Aurora. Pour en savoir plus sur la configuration d'un CNAME DNS, consultez la documentation Cloud DNS ou la documentation AWS Route53.
Les journaux binaires doivent être stockés sur un stockage en bloc standard et ne peuvent pas être stockés sur Amazon S3.
Pour créer un job de migration continu avec un vidage manuel fourni,
GTIDdoit être activé.GTID_MODEdoit être ON, OFF ou OFF_PERMISSIVE. La valeurGTID_MODEde ON_PERMISSIVE n'est pas acceptée.Pour effectuer le vidage complet initial, arrêtez les écritures MySQL Amazon Aurora dans la base de données source pendant environ 20 secondes.
Le service de migration de base de données ne peut pas migrer les données d'une instance de réplication en lecture seule Amazon Aurora d'un cluster de base de données MySQL, car les fichiers journaux binaires ne peuvent pas être récupérés à partir de l'instance. Pour en savoir plus, consultez la documentation Amazon sur la configuration de la journalisation binaire MySQL Aurora.
Exécuter la tâche de migration
Pour effectuer le vidage complet initial, arrêtez les écritures MySQL Amazon Aurora dans la base de données source pendant environ 20 secondes. Vous pouvez utiliser un script qui recherche les activités d'écriture pour vérifier que toutes les écritures dans la base de données source sont arrêtées.
L'état et le sous-état de la tâche de migration indiquent quand arrêter et reprendre les écritures. Vous pouvez suivre les modifications d'état dans l'API, la console ou directement dans Cloud Monitoring:
Une fois que l'état passe à Démarrage | En attente de l'arrêt des écritures sources, les écritures doivent être arrêtées dans la base de données source. Database Migration Service détecte que l'écriture s'est arrêtée et l'état passe à En cours d'exécution | Préparation du vidage.
Une fois que l'état passe à Running | Full dump in progress (En cours d'exécution | Vidage complet en cours), vous pouvez reprendre l'écriture dans la base de données source.
Database Migration Service tente de créer le dump initial pendant environ 20 minutes. Si les écritures n'ont pas été arrêtées ou si elles sont reprises avant la mise à jour de l'état, le processus échoue et renvoie une erreur décrivant la cause de l'échec.