Migrer depuis Amazon Aurora MySQL sans droits SUPER-UTILISATEUR
Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
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, GTID doit être activé. GTID_MODE doit être ON, OFF ou OFF_PERMISSIVE.
La valeur GTID_MODE de 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.
Database Migration Service 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 dans la base de données source doivent être arrêtées. 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 vidage 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.
Sauf indication contraire, le contenu de cette page est régi par une licence Creative Commons Attribution 4.0, et les échantillons de code sont régis par une licence Apache 2.0. Pour en savoir plus, consultez les Règles du site Google Developers. Java est une marque déposée d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/09/05 (UTC).
[[["Facile à comprendre","easyToUnderstand","thumb-up"],["J'ai pu résoudre mon problème","solvedMyProblem","thumb-up"],["Autre","otherUp","thumb-up"]],[["Difficile à comprendre","hardToUnderstand","thumb-down"],["Informations ou exemple de code incorrects","incorrectInformationOrSampleCode","thumb-down"],["Il n'y a pas l'information/les exemples dont j'ai besoin","missingTheInformationSamplesINeed","thumb-down"],["Problème de traduction","translationIssue","thumb-down"],["Autre","otherDown","thumb-down"]],["Dernière mise à jour le 2025/09/05 (UTC)."],[[["\u003cp\u003eMigrations from Amazon Aurora MySQL sources without SUPERUSER privileges require specific adjustments to the migration process.\u003c/p\u003e\n"],["\u003cp\u003eSource hostnames longer than 60 characters require configuring a DNS redirect with a CNAME record.\u003c/p\u003e\n"],["\u003cp\u003eBinary logs must be stored on standard block storage, not Amazon S3, for migration jobs.\u003c/p\u003e\n"],["\u003cp\u003eFor initial full dumps, it is necessary to stop writes to the source MySQL Amazon Aurora database for around 20 seconds, using scripts to identify when to stop.\u003c/p\u003e\n"],["\u003cp\u003eDatabase Migration Service cannot migrate data from an Amazon Aurora read-only replica instance because it cannot retrieve binary log files from the instance.\u003c/p\u003e\n"]]],[],null,["# Migrating from Amazon Aurora MySQL without SUPERUSER privileges\n\n\u003cbr /\u003e\n\nWhen you create and run a migration job with an Amazon Aurora MySQL source or\nsources that don't allow SUPERUSER privileges, the migration can require additional steps.\n\nCreate the Amazon Aurora MySQL migration job\n--------------------------------------------\n\nMake sure you consider the following requirements and adjust your migration process:\n\n1. MySQL limits the source hostname definition to 60 characters. Amazon Aurora\n databases hostnames will typically be longer than 60 characters. If this\n is the case for the database you are migrating, configure\n a DNS redirect to create a\n [CNAME record](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resource-record-sets-choosing-alias-non-alias.html)\n that associates your domain name with the domain name of your Amazon Aurora\n database instance. For more information about setting up DNS CNAME, see the\n [Cloud DNS documentation](/dns/docs/set-up-dns-records-domain-name) or the\n [AWS Route53 documentation](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-to-rds-db.html).\n\n2. Binary logs must be stored on standard block storage and cannot be stored\n on Amazon S3.\n\n3. Creating a continuous migration job with a manual dump provided requires\n `GTID` to be enabled. `GTID_MODE` must be either\n \u003cvar translate=\"no\"\u003eON\u003c/var\u003e, \u003cvar translate=\"no\"\u003eOFF\u003c/var\u003e, or \u003cvar translate=\"no\"\u003eOFF_PERMISSIVE\u003c/var\u003e.\n The `GTID_MODE` value of \u003cvar translate=\"no\"\u003eON_PERMISSIVE\u003c/var\u003e isn't supported.\n\n4. To take the initial full dump, stop MySQL Amazon Aurora writes at the\n source database for approximately 20 seconds.\n\n5. Database Migration Service can't migrate data from an Amazon Aurora read-only replica instance of a MySQL database cluster because\n binary log files can't be retrieved from the instance. For more information, see the Amazon documentation about\n [configuring Aurora MySQL binary logging](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_LogAccess.MySQL.BinaryFormat.html).\n\nRun the migration job\n---------------------\n\nTo take the initial full dump, stop MySQL Amazon Aurora writes\nat the source database for approximately 20 seconds. You can use a script that [finds write activities](/database-migration/docs/mysql/debugging-tools#write-activities) to verify that all writing to the source database is stopped.\n\nIndication of when to stop and resume writes is in the status and substatus of\nthe migration job. The status changes can be tracked in the API, Console or\ndirectly in Cloud Monitoring:\n\n1. After the status changes to **Starting \\| Waiting for source writes to stop** ,\n writing should be stopped to the source database. Database Migration Service identifies that the writing stopped, and the status changes to **Running \\| Preparing the dump**.\n\n2. After the status changes to **Running \\| Full dump in progress**, it's safe\n to resume writing to the source database.\n\nDatabase Migration Service keeps trying to take the initial dump for approximately 20 minutes. If writes haven't been stopped, or if writes are resumed before the status update, then the process fails and returns an error describing the cause of the failure."]]