Cómo migrar desde MySQL de Amazon Aurora sin privilegios de SUPERUSER
Organiza tus páginas con colecciones
Guarda y categoriza el contenido según tus preferencias.
Cuando creas y ejecutas un trabajo de migración con una fuente de MySQL de Amazon Aurora o fuentes que no permiten privilegios de SUPERUSUARIO, la migración puede requerir pasos adicionales.
Crea el trabajo de migración de MySQL a Amazon Aurora
Asegúrate de tener en cuenta los siguientes requisitos y de ajustar tu proceso de migración:
MySQL limita la definición del nombre de host de origen a 60 caracteres. Por lo general, los nombres de host de las bases de datos de Amazon Aurora tienen más de 60 caracteres. Si este es el caso de la base de datos que migras, configura un redireccionamiento de DNS para crear un registro CNAME que asocie tu nombre de dominio con el nombre de dominio de tu instancia de base de datos de Amazon Aurora. Para obtener más información sobre cómo configurar un CNAME de DNS, consulta la documentación de Cloud DNS o la documentación de AWS Route53.
Los registros binarios deben almacenarse en el almacenamiento en bloques estándar y no se pueden almacenar en Amazon S3.
Para crear un trabajo de migración continuo con un volcado manual, se requiere que GTID esté habilitado. GTID_MODE debe ser ON, OFF o OFF_PERMISSIVE.
No se admite el valor GTID_MODE de ON_PERMISSIVE.
Para tomar el volcado completo inicial, detén las operaciones de escritura de MySQL Amazon Aurora en la base de datos de origen durante aproximadamente 20 segundos.
Database Migration Service no puede migrar datos desde una instancia de réplica de solo lectura de Amazon Aurora de un clúster de bases de datos de MySQL porque los archivos de registro binarios no se pueden recuperar de la instancia. Para obtener más información, consulta la documentación de Amazon sobre
cómo configurar el registro binario de Aurora MySQL.
Ejecuta el trabajo de migración
Para tomar el volcado completo inicial, detén las operaciones de escritura de MySQL Amazon Aurora en la base de datos de origen durante aproximadamente 20 segundos. Puedes usar una secuencia de comandos que
encuentre actividades de escritura para verificar que se detenga toda la escritura en la base de datos de origen.
La indicación de cuándo detener y reanudar las operaciones de escritura se encuentra en el estado y el subestado del trabajo de migración. Puedes hacer un seguimiento de los cambios de estado en la API, Console o
directamente en Cloud Monitoring:
Después de que el estado cambie a Iniciando | Esperando a que se detengan las escrituras de la fuente, se deben detener las operaciones de escritura en la base de datos de origen. Database Migration Service identifica que se detuvo la escritura y el estado cambia a Running | Preparing the dump.
Una vez que el estado cambie a En ejecución | Volcado completo en curso, es seguro reanudar la escritura en la base de datos de origen.
Database Migration Service sigue intentando realizar el volcado inicial durante aproximadamente 20 minutos. Si no se detuvieron las operaciones de escritura o si se reanudan antes de la actualización de estado, el proceso falla y muestra un error que describe la causa de la falla.
[[["Fácil de comprender","easyToUnderstand","thumb-up"],["Resolvió mi problema","solvedMyProblem","thumb-up"],["Otro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Información o código de muestra incorrectos","incorrectInformationOrSampleCode","thumb-down"],["Faltan la información o los ejemplos que necesito","missingTheInformationSamplesINeed","thumb-down"],["Problema de traducción","translationIssue","thumb-down"],["Otro","otherDown","thumb-down"]],["Última actualización: 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."]]
