Migration von Amazon Aurora MySQL ohne SUPERUSER-Berechtigungen
Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
Wenn Sie einen Migrationsjob mit einer Amazon Aurora-MySQL-Quelle oder Quellen erstellen und ausführen, die keine SUPERUSER-Berechtigungen zulassen, sind für die Migration möglicherweise zusätzliche Schritte erforderlich.
Amazon Aurora MySQL-Migrationsjob erstellen
Berücksichtigen Sie die folgenden Anforderungen und passen Sie Ihren Migrationsprozess entsprechend an:
MySQL begrenzt die Definition des Quell-Hostnamens auf 60 Zeichen. Hostnamen von Amazon Aurora-Datenbanken sind in der Regel länger als 60 Zeichen. Wenn dies für die migrierte Datenbank der Fall ist, konfigurieren Sie eine DNS-Weiterleitung, um einen CNAME-Eintrag zu erstellen, der Ihren Domainnamen mit dem Domainnamen Ihrer Amazon Aurora-Datenbankinstanz verknüpft. Weitere Informationen zum Einrichten eines DNS-CNAME finden Sie in der Cloud DNS-Dokumentation oder in der AWS Route53-Dokumentation.
Binäre Protokolle müssen in Standard-Blockspeichern gespeichert werden und können nicht in Amazon S3 gespeichert werden.
Wenn Sie einen fortlaufenden Migrationsjob mit einem manuellen Dump erstellen möchten, muss GTID aktiviert sein. GTID_MODE muss entweder ON, OFF oder OFF_PERMISSIVE sein.
Der GTID_MODE-Wert ON_PERMISSIVE wird nicht unterstützt.
Um den ersten vollständigen Dump zu erstellen, halten Sie die MySQL-Amazon Aurora-Schreibvorgänge in der Quelldatenbank für etwa 20 Sekunden an.
Der Database Migration Service kann keine Daten aus einer schreibgeschützten Replika-Instanz von Amazon Aurora eines MySQL-Datenbankclusters migrieren, da keine Binärprotokolldateien aus der Instanz abgerufen werden können. Weitere Informationen finden Sie in der Amazon-Dokumentation zum
Konfigurieren des binären Loggings für Aurora MySQL.
Migrationsjob ausführen
Um den ersten vollständigen Dump zu erstellen, halten Sie die MySQL Amazon Aurora-Schreibvorgänge in der Quelldatenbank für etwa 20 Sekunden an. Sie können ein Script verwenden, mit dem
Schreibaktivitäten gefunden werden, um zu prüfen, ob alle Schreibvorgänge in der Quelldatenbank beendet wurden.
Informationen dazu, wann Schreibvorgänge angehalten und fortgesetzt werden, finden Sie im Status und Unterstatus des Migrationsjobs. Die Statusänderungen können in der API, in der Console oder direkt in Cloud Monitoring beobachtet werden:
Nachdem sich der Status in Startet | Warten auf Ende der Quellschreibvorgänge geändert hat, sollten Schreibvorgänge in der Quelldatenbank beendet werden. Database Migration Service erkennt, dass das Schreiben beendet wurde, und der Status ändert sich zu Wird ausgeführt | Dump wird vorbereitet.
Sobald der Status zu Wird ausgeführt | Vollständiger Dump läuft wechselt, können Sie das Schreiben in die Quelldatenbank fortsetzen.
Der Database Migration Service versucht etwa 20 Minuten lang, den ersten Dump zu erstellen. Wenn Schreibvorgänge nicht beendet wurden oder vor der Statusaktualisierung fortgesetzt werden, schlägt der Vorgang fehl und es wird ein Fehler zurückgegeben, der die Ursache des Fehlers beschreibt.
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Schwer verständlich","hardToUnderstand","thumb-down"],["Informationen oder Beispielcode falsch","incorrectInformationOrSampleCode","thumb-down"],["Benötigte Informationen/Beispiele nicht gefunden","missingTheInformationSamplesINeed","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 2025-08-18 (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."]]
