Migrazione da Amazon Aurora MySQL senza privilegi SUPERUSER
Mantieni tutto organizzato con le raccolte
Salva e classifica i contenuti in base alle tue preferenze.
Quando crei ed esegui un job di migrazione con un'origine MySQL di Amazon Aurora o con origini che non consentono i privilegi SUPERUSER, la migrazione può richiedere passaggi aggiuntivi.
Crea il job di migrazione di MySQL di Amazon Aurora
Assicurati di prendere in considerazione i seguenti requisiti e di modificare il processo di migrazione:
MySQL limita la definizione del nome host di origine a 60 caratteri. In genere, i nomi host dei database Amazon Aurora sono più lunghi di 60 caratteri. Se questo è il caso del database di cui stai eseguendo la migrazione, configura un reindirizzamento DNS per creare un record CNAME che associ il tuo nome di dominio al nome di dominio dell'istanza del database Amazon Aurora. Per ulteriori informazioni sulla configurazione del CNAME DNS, consulta la documentazione di Cloud DNS o la documentazione di AWS Route53.
I log binari devono essere archiviati in un'archiviazione a blocchi standard e non possono essere archiviati su Amazon S3.
Per creare un job di migrazione continua con un dump manuale fornito, è necessario attivare GTID. GTID_MODE deve essere
ON, OFF o OFF_PERMISSIVE.
Il valore GTID_MODE di ON_PERMISSIVE non è supportato.
Per eseguire il dump completo iniziale, interrompi le scritture di MySQL Amazon Aurora nel database di origine per circa 20 secondi.
Database Migration Service non può eseguire la migrazione dei dati da un'istanza di replica di sola lettura di Amazon Aurora di un cluster di database MySQL perché
non è possibile recuperare i file di log binari dall'istanza. Per ulteriori informazioni, consulta la documentazione di Amazon sulla
configurazione del logging binario di Aurora MySQL.
Esegui il job di migrazione
Per eseguire il dump completo iniziale, interrompi le scritture di MySQL Amazon Aurora
nel database di origine per circa 20 secondi. Puoi utilizzare uno script che
individua le attività di scrittura per verificare che tutte le scritture nel database di origine siano state interrotte.
L'indicazione di quando interrompere e riprendere le scritture è nello stato e nello stato secondario del job di migrazione. Le modifiche dello stato possono essere monitorate nell'API, nella console o direttamente in Cloud Monitoring:
Quando lo stato diventa In fase di avvio | In attesa dell'arresto delle scritture dell'origine,
la scrittura nel database di origine deve essere interrotta. Database Migration Service rileva che la scrittura è stata interrotta e lo stato diventa In esecuzione | Preparazione del dump.
Quando lo stato diventa In esecuzione | Dump completo in corso, puoi riprendere la scrittura nel database di origine.
Database Migration Service continua a tentare di eseguire il dump iniziale per circa 20 minuti. Se le scritture non sono state interrotte o se vengono riprese prima dell'aggiornamento dello stato, il processo non va a buon fine e viene restituito un errore che descrive la causa dell'errore.
[[["Facile da capire","easyToUnderstand","thumb-up"],["Il problema è stato risolto","solvedMyProblem","thumb-up"],["Altra","otherUp","thumb-up"]],[["Difficile da capire","hardToUnderstand","thumb-down"],["Informazioni o codice di esempio errati","incorrectInformationOrSampleCode","thumb-down"],["Mancano le informazioni o gli esempi di cui ho bisogno","missingTheInformationSamplesINeed","thumb-down"],["Problema di traduzione","translationIssue","thumb-down"],["Altra","otherDown","thumb-down"]],["Ultimo aggiornamento 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."]]
