Migrer depuis Amazon Aurora MySQL sans droits SUPER-UTILISATEUR

Lorsque vous créez et exécutez un job de migration avec une source Amazon Aurora MySQL ou des sources qui n'autorisent pas les droits SUPERUSER, la migration peut nécessiter des étapes supplémentaires.

Créer le job de migration Amazon Aurora MySQL

Assurez-vous de prendre en compte les exigences suivantes et d'ajuster votre processus de migration :

  1. 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 sont généralement plus longs que 60 caractères. Si c'est ce 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.

  2. Les journaux binaires doivent être stockés sur un stockage de blocs standard et ne peuvent pas être stockés sur Amazon S3.

  3. La création d'un job de migration continu avec un vidage manuel fourni nécessite l'activation de GTID. GTID_MODE doit être défini sur ON, OFF, ou OFF_PERMISSIVE. La valeur ON_PERMISSIVE de GTID_MODE n'est pas acceptée.

  4. Pour effectuer le vidage complet initial, arrêtez les écritures MySQL Amazon Aurora dans la base de données source pendant environ 20 secondes.

  5. Database Migration Service ne peut pas migrer les données d'une instance dupliquée 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 Aurora MySQL.

Exécuter le job 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'indication du moment où arrêter et reprendre les écritures se trouve dans l'état et le sous-état du job de migration. Les changements d'état peuvent être suivis dans l'API, la console ou directement dans Cloud Monitoring :

  1. Une fois l'état passé à Démarrage | En attente de l'arrêt des écritures sources, l'écriture doit être arrêtée dans la base de données source. Database Migration Service identifie que l'écriture est arrêtée et l'état passe à En cours d'exécution | Préparation du vidage.

  2. Une fois l'état passé à 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 d'effectuer le vidage initial pendant environ 20 minutes. Si les écritures n'ont pas été arrêtées ou si elles ont repris avant la mise à jour de l'état, le processus échoue et renvoie une erreur décrivant la cause de l'échec.