View a markdown version of this page

Verwenden einer MySQL-compatible Datenbank als Quelle für AWS DMS - AWS Datenbankmigrationsdienst
Migrieren von MySQL auf MySQLVerwenden von MySQL als QuelleVerwenden einer selbstverwalteten MySQL-DB als QuelleVerwendung von AWS-managed MySQL als QuelleAurora MySQL 8.4-QuellenEinschränkungen für MySQL als QuelleUnterstützung für XA-TransaktionenEndpunkteinstellungenQuelldatentypen für MySQL

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Verwenden einer MySQL-compatible Datenbank als Quelle für AWS DMS

Mit dem Database Migration Service können Sie Daten aus jeder MySQL-compatible Datenbank (MySQL, MariaDB oder Amazon Aurora MySQL AWS ) migrieren.

Hinweise zu Versionen von MySQL, die als Quelle AWS DMS unterstützt werden, finden Sie unter. Quellen für AWS DMS

Sie können SSL verwenden, um Verbindungen zwischen Ihrem MySQL-compatible Endpunkt und der Replikationsinstanz zu verschlüsseln. Weitere Informationen zur Verwendung von SSL mit einem MySQL-compatible Endpunkt finden Sie unterVerwenden von SSL mit AWS Database Migration Service.

In den folgenden Abschnitten bezieht sich der Begriff „selbstverwaltet“ auf Datenbanken, die entweder On-Premises oder in Amazon EC2 installiert sind. Der Begriff „von AWS verwaltet“ bezieht sich auf Datenbanken in Amazon RDS, Amazon Aurora oder Amazon S3.

Weitere Informationen zum Arbeiten mit MySQL-compatible Datenbanken und AWS DMS finden Sie in den folgenden Abschnitten.

Anmerkung

Bei der Konfiguration von AWS Database Migration Service (AWS DMS) -Zuordnungsregeln ist es wichtig, die Verwendung von Platzhaltern (%) für Datenbank- oder Schemanamen zu vermeiden. Stattdessen müssen Sie explizit nur die vom Benutzer erstellten Datenbanken angeben, die migriert werden müssen. Die Verwendung eines Platzhalterzeichens schließt alle Datenbanken in den Migrationsprozess ein, einschließlich Systemdatenbanken, die auf der Zielinstanz nicht benötigt werden. Da der MySQL Amazon RDS-Master-Benutzer nicht über die erforderlichen Berechtigungen zum Importieren von Daten in Zielsystemdatenbanken verfügt, schlägt der Versuch, diese Systemdatenbanken zu migrieren, fehl.

Migration von MySQL zu MySQL mit AWS DMS

Für eine heterogene Migration, bei der Sie von einer anderen Datenbank-Engine als MySQL zu einer MySQL-Datenbank migrieren, AWS DMS ist dies fast immer das beste Migrationstool. Für eine homogene Migration, bei der Sie von einer MySQL-Datenbank auf eine MySQL-Datenbank migrieren, empfehlen wir jedoch, ein Migrationsprojekt für homogene Datenmigrationen zu verwenden. Bei homogenen Datenmigrationen werden native Datenbanktools verwendet, um im Vergleich zu AWS DMS eine bessere Leistung und Genauigkeit bei der Datenmigration zu erzielen.

Verwenden einer beliebigen MySQL-compatible Datenbank als Quelle für AWS DMS

Bevor Sie beginnen, mit einer MySQL-Datenbank als Quelle für zu arbeiten AWS DMS, stellen Sie sicher, dass Sie die folgenden Voraussetzungen erfüllen. Diese Voraussetzungen gelten entweder für selbstverwaltete oder für AWS verwaltete Quellen.

Sie müssen über ein Konto mit der Rolle AWS DMS „Replikationsadministrator“ verfügen. Die Rolle benötigt die folgenden Berechtigungen:

  • REPLICATION CLIENT – Diese Berechtigung ist nur für CDC-Aufgaben erforderlich. Mit anderen Worten: "Vollständiges Laden"-Aufgaben benötigen diese Berechtigung nicht.

    Anmerkung

    Für MariaDB Version 10.5.2+ können Sie BINLOG MONITOR verwenden — es ist ein Ersatz für REPLICATION CLIENT.

  • REPLICATION SLAVE – Diese Berechtigung ist nur für CDC-Aufgaben erforderlich. Mit anderen Worten: "Vollständiges Laden"-Aufgaben benötigen diese Berechtigung nicht.

  • SUPER – Diese Berechtigung ist nur für MySQL-Versionen vor 5.6.6 erforderlich.

Der AWS DMS Benutzer muss außerdem über SELECT-Rechte für die Quelltabellen verfügen, die für die Replikation vorgesehen sind.

Gewähren Sie die folgenden Berechtigungen, wenn Sie Prüfungen MySQL-specific vor der Migration verwenden:

grant select on mysql.user to <dms_user>;
grant select on mysql.db to <dms_user>;
grant select on mysql.tables_priv to <dms_user>;
grant select on mysql.role_edges to <dms_user>  #only for MySQL version 8.0.11 and higher
grant select on performance_schema.replication_connection_status to <dms_user>;  #Required for primary instance validation - MySQL version 5.7 and higher only

Wenn Sie eine RDS-Quelle verwenden und beabsichtigen, Prüfungen MySQL-specific vor der Migration durchzuführen, fügen Sie die folgende Berechtigung hinzu:

grant select on mysql.rds_configuration to <dms_user>;  #Required for binary log retention check

Wenn true es BatchEnable sich um einen Parameter handelt, muss er Folgendes gewähren:

grant create temporary tables on `<schema>`.* to <dms_user>;

Verwendung einer selbstverwalteten MySQL-compatible Datenbank als Quelle für AWS DMS

Sie können die folgenden selbstverwalteten MySQL-compatible Datenbanken als Quellen für verwenden: AWS DMS

  • MySQL Community Edition

  • MySQL Standard Edition

  • MySQL Enterprise Edition

  • MySQL Cluster Carrier Grade Edition

  • MariaDB Community Edition

  • MariaDB Enterprise Edition

  • MariaDB Column Store

Stellen Sie sicher, dass die binäre Protokollierung aktiviert ist, damit Sie CDC verwenden können. Um die binäre Protokollierung zu aktivieren, müssen die folgenden Parameter in der MySQL-Datei my.ini (Windows) oder my.cnf (UNIX) konfiguriert werden.

Parameter

Wert

server_id

Legen Sie diesen Parameter auf einen Wert von 1 oder größer fest.

log-bin

Legen Sie den Pfad zur binären Protokolldatei fest, z. B. log-bin=E:\MySql_Logs\BinLog. Schließen Sie nicht die Dateierweiterung ein.

binlog_format

Legen Sie diesen Parameter auf ROW fest. Wir empfehlen, diese Einstellung während der Replikation zu verwenden, da es in gewissen Fällen zu Inkonsistenzen bei der Replikation von Daten auf das Ziel kommen kann, wenn binlog_format auf STATEMENT festgelegt ist. Die Datenbank-Engine schreibt auch ähnlich inkonsistente Daten in das Ziel, wenn binlog_format auf MIXED festgelegt ist, da die Datenbank-Engine automatisch zur STATEMENT-basierten Protokollierung wechselt. Dies kann dazu führen, dass inkonsistente Daten in die Zieldatenbank geschrieben werden.

expire_logs_days

oder

binlog_expire_logs_seconds

Der Parameter expire_logs_days ist seit MySQL 8.0 veraltet und wurde in MySQL 8.4 entfernt. Weitere Informationen finden Sie unter Server- und Statusvariablen und Optionen in MySQL 8.4 seit 8.0 hinzugefügt, veraltet oder entfernt.

Verwenden Sie den expire_logs_days Parameter für MySQL 5.x. Wir empfehlen, dass Sie diesen Parameter auf 1 oder höher setzen, siehe Optionen und Variablen für die binäre Protokollierung.

Verwenden Sie den binlog_expire_logs_seconds Parameter für MySQL 8.0 und höher. Wir empfehlen, diesen Parameter auf einen Wert von 86400 Sekunden (1 Tag) oder höher einzustellen. Siehe Optionen und Variablen für die binäre Protokollierung.

binlog_checksum

Setzen Sie diesen Parameter NONE für DMS-Version 3.4.7 oder früher auf.

binlog_row_image

Legen Sie diesen Parameter auf FULL fest.

log_slave_updates

Setzen Sie diesen Parameter auf TRUE, wenn Sie eine Read Replica von MySQL oder MariaDB als Quelle verwenden.

Wenn Sie eine MySQL- oder MariaDB-Read-Replica als Quelle für eine DMS-Migrationsaufgabe verwenden, indem Sie den Modus „Vorhandene Daten migrieren und laufende Änderungen replizieren“ verwenden, besteht die Möglichkeit eines Datenverlusts. DMS schreibt unter den folgenden Bedingungen weder bei Volllast noch bei CDC eine Transaktion:

  • Die Transaktion wurde vor dem Start der DMS-Aufgabe an die primäre Instanz übertragen.

  • Die Transaktion wurde aufgrund einer Verzögerung zwischen der Primärinstanz und dem Replikat erst nach dem Start der DMS-Aufgabe für das Replikat festgeschrieben.

Je länger die Verzögerung zwischen der primären Instance und dem Replikat ist, desto größer ist das Risiko eines Datenverlusts.

Sofern Ihre Quelle die (geclusterte) NDB-Datenbank-Engine nutzt, müssen die folgenden Parameter konfiguriert werden, um CDC auf Tabellen zu aktivieren, die diese Speicher-Engine verwenden. Fügen Sie diese Änderungen in der MySQL-Datei my.ini (Windows) oder my.cnf (UNIX) hinzu.

Parameter

Wert

ndb_log_bin

Legen Sie diesen Parameter auf ON fest. Dieser Wert stellt sicher, dass Änderungen in geclusterten Tabellen im binären Protokoll protokolliert werden.

ndb_log_update_as_write

Legen Sie diesen Parameter auf OFF fest. Dieser Wert verhindert das Schreiben von UPDATE-Anweisungen als INSERT-Anweisungen in das Binärprotokoll.

ndb_log_updated_only

Legen Sie diesen Parameter auf OFF fest. Dieser Wert stellt sicher, dass das Binärprotokoll die gesamte Zeile enthält und nicht nur die geänderten Spalten.

Unter Verwendung einer AWS-verwaltete MySQL-compatible Datenbank als Quelle für AWS DMS

Sie können die folgenden AWS verwalteten MySQL-compatible Datenbanken als Quellen für verwenden: AWS DMS

  • MySQL Community Edition

  • MariaDB Community Edition

  • Amazon Aurora-Ausgabe MySQL-Compatible

Wenn Sie eine AWS verwaltete MySQL-compatible Datenbank als Quelle für verwenden, stellen Sie sicher AWS DMS, dass Sie die folgenden Voraussetzungen für CDC erfüllen:

  • Aktivieren Sie automatische Backups auf Instance-Ebene, um Binärprotokolle für RDS für MySQL und für RDS für MariaDB zu aktivieren. Ändern Sie die Variable binlog_format in der Parametergruppe, um Binärprotokolle für einen Aurora-MySQL-Cluster zu aktivieren.

    Weitere Informationen zum Einrichten von automatischen Backups finden Sie unter Working with automated backups im Benutzerhandbuch für Amazon RDS.

    Weitere Informationen zum Einrichten der Binärprotokollierung für eine Datenbank von Amazon RDS für MySQL finden Sie unter Setting the binary logging format im Benutzerhandbuch für Amazon RDS.

    Weitere Informationen zum Einrichten der Binärprotokollierung für einen Aurora-MySQL-Cluster finden Sie unter Wie aktiviere ich die Binärprotokollierung für meinen Amazon-Aurora-MySQL-kompatiblen Cluster?.

  • Wenn Sie CDC verwenden möchten, aktivieren Sie die Binärprotokollierung. Weitere Informationen zum Einrichten der Binärprotokollierung für eine Datenbank von Amazon RDS für MySQL finden Sie unter Setting the binary logging format im Benutzerhandbuch für Amazon RDS.

  • Stellen Sie sicher, dass die Binärprotokolle für verfügbar sind. AWS DMS Da AWS-verwaltete MySQL-compatible Datenbanken die Binärprotokolle so schnell wie möglich löschen, sollten Sie den Zeitraum verlängern, in dem die Protokolle verfügbar bleiben. Um z. B. die Aufbewahrungszeit der Protokolle auf 24 Stunden zu verlängern, führen Sie den folgenden Befehl aus. 

    
 call mysql.rds_set_configuration('binlog retention hours', 24);

  • Stellen Sie den Parameter binlog_format auf "ROW" ein.

    Anmerkung

    In MySQL oder MariaDB ist binlog_format ein dynamischer Parameter, sodass kein Neustart erforderlich ist, damit der neue Wert wirksam wird. Der neue Wert gilt jedoch nur für neue Sitzungen. Wenn Sie binlog_format zu Replikationszwecken in ROW ändern, kann Ihre Datenbank weiterhin nachfolgende Binärprotokolle mit dem Format MIXED erstellen, sofern diese Sitzungen gestartet wurden, bevor der Wert geändert wurde. Dies kann AWS DMS verhindern, dass alle Änderungen in der Quelldatenbank ordnungsgemäß erfasst werden. Wenn Sie die Einstellung binlog_format für eine MariaDB- oder MySQL-Datenbank ändern, starten Sie die Datenbank unbedingt neu, um alle vorhandenen Sitzungen zu beenden, oder starten Sie alle Anwendungen neu, die Data Manipulation Language (DML)-Operationen ausführen. Wenn Sie Ihre Datenbank zwingen, alle Sitzungen neu zu starten, nachdem Sie den binlog_format Parameter geändert haben, ROW wird sichergestellt, dass Ihre Datenbank alle nachfolgenden Änderungen an der Quelldatenbank im richtigen Format schreibt, sodass diese Änderungen ordnungsgemäß erfasst werden AWS DMS können.

  • Stellen Sie den Parameter binlog_row_image auf "Full" ein.

  • Setzen Sie den binlog_checksum Parameter auf "NONE" für DMS-Version 3.4.7 oder früher. Weitere Informationen zum Festlegen von Parametern in Amazon RDS MySQL finden Sie unter Working with automated backups im Benutzerhandbuch für Amazon RDS.

  • Wenn Sie ein Lesereplikat von Amazon RDS MySQL oder Amazon RDS MariaDB als Quelle verwenden, aktivieren Sie für das Lesereplikat Backups und stellen Sie sicher, dass der Parameter log_slave_updates auf TRUE gesetzt ist.

Weitere Informationen zu den Sicherheitsänderungen in Aurora MySQL 8.4 finden Sie unter Sicherheit mit Amazon Aurora MySQL und Passwortverwaltung mit Amazon Aurora und Secrets Manager im Amazon Aurora-Benutzerhandbuch.

Überlegungen zu Aurora MySQL 8.4-Quellen

Aurora MySQL 8.4 führt Sicherheitsänderungen ein, die sich auf die Konnektivität der AWS DMS Quellendpunkte auswirken können. Überprüfen Sie Folgendes, bevor Sie Ihre Aurora MySQL-Quelle auf Version 8.4 aktualisieren.

Durchsetzung von TLS

Aurora MySQL 8.4 ist ON standardmäßig require_secure_transport auf eingestellt, was bedeutet, dass alle Verbindungen TLS verwenden müssen. Wenn Ihr AWS DMS Quellendpunkt eine Verbindung zu Aurora MySQL 8.4 herstellt und der SSL-Modus auf None gesetzt ist, werden Verbindungen abgelehnt. Wenn Ihr Endpunkt-SSL-Modus auf „Keine“ gesetzt ist, erhalten Sie die folgende Fehlermeldung:MySQL Error 3159 (HY000): Connections using insecure transport are prohibited while --require_secure_transport=ON. Stellen Sie den Endpunkt-SSL-Modus auf verify-ca oder verify-full ein. Für beide Modi ist ein CA-Zertifikat erforderlich. Stellen Sie require_secure_transport alternativ OFF in Ihrer Aurora-Cluster-Parametergruppe auf auf ein, um unverschlüsselte Verbindungen zuzulassen.

Anmerkung

Aurora MySQL 8.4 unterstützt nur GCM-Verschlüsselungssammlungen für TLS 1.2. Alle CBC-mode Chiffren wurden entfernt. AWS DMS verwendet TLS 1.2 für MySQL- und Aurora MySQL-Endpunkte und handelt automatisch eine unterstützte GCM-Verschlüsselung aus. Wenn Sie benutzerdefinierte Verschlüsselungskonfigurationen haben, stellen Sie sicher, dass sie eine der folgenden unterstützten Verschlüsselungen enthalten:,, oder. ECDHE-RSA-AES128-GCM-SHA256 ECDHE-RSA-AES256-GCM-SHA384 ECDHE-ECDSA-AES128-GCM-SHA256 ECDHE-ECDSA-AES256-GCM-SHA384

Anmerkung

AWS DMS unterstützt TLS 1.3 für MySQL-Endpunkte nicht. Dies hat keinen Einfluss auf die Konnektivität zu Aurora MySQL 8.4, da Aurora MySQL 8.4 weiterhin TLS 1.2 unterstützt.

Authentifizierung (Aurora MySQL und RDS für MySQL 8.4)

Aurora MySQL 8.4 ersetzt den default_authentication_plugin Parameter durchauthentication_policy, der standardmäßig auf*:caching_sha2_password. Bestehende Datenbankbenutzer behalten ihr aktuelles Authentifizierungs-Plugin nach dem Upgrade bei. Wenn Sie nach dem Upgrade neue AWS DMS Endpunktbenutzer erstellen, werden diese caching_sha2_password standardmäßig verwendet, sofern Sie dies nicht *:mysql_native_password in Ihrer Cluster-Parametergruppe festgelegt authentication_policy haben.

Das Passwort des Hauptbenutzers wurde zurückgesetzt

Nach dem Upgrade auf Aurora MySQL 8.4 setzt das Zurücksetzen des Masterbenutzer-Passworts über die AWS-Managementkonsole CLI oder die Secrets Manager-Rotation das Authentifizierungs-Plugin des Masterbenutzers auf die durch den authentication_policy Parameter definierte Standardeinstellung zurück. Wenn authentication_policy es auf den Standardwert (*:caching_sha2_password) gesetzt ist, wechselt das Authentifizierungs-Plugin des Hauptbenutzers beim nächsten Zurücksetzen des Passworts von mysql_native_password caching_sha2_password auf.

Wenn Ihr AWS DMS Quellendpunkt das Hauptbenutzerkonto verwendet, überprüfen Sie die Konnektivität nach jedem Zurücksetzen des Kennworts. Um Änderungen am Authentifizierungs-Plugin zu vermeiden, gehen Sie entweder wie folgt vor:

  • Stellen authentication_policy Sie dies *:mysql_native_password in Ihrer Cluster-Parametergruppe ein, bevor Sie das Passwort zurücksetzen, oder

  • Erstellen Sie einen dedizierten AWS DMS Endpunktbenutzer mit einem explizit angegebenen Authentifizierungs-Plugin (empfohlen). Beispiel: CREATE USER 'dms_user'@'%' IDENTIFIED WITH mysql_native_password BY 'password';

Einschränkungen bei der Verwendung einer MySQL-Datenbank als Quelle für AWS DMS

Wenn Sie eine MySQL-Datenbank als Quelle verwenden, sollten Sie Folgendes beachten:

  • Die Erfassung von Datenänderungen (Change Data Capture, CDC) wird für Amazon RDS MySQL 5.5 oder frühere Versionen nicht unterstützt. Für Amazon RDS MySQL müssen Sie die Version 5.6, 5.7 oder 8.0 verwenden, um CDC zu aktivieren. CDC wird für selbstverwaltete MySQL-5.5-Quellen unterstützt.

  • Für CDC werden CREATE TABLE, ADD COLUMN und DROP COLUMN zur Änderung des Spaltendatentyps und renaming a column unterstützt. DROP TABLE, RENAME TABLE und Änderungen an anderen Attributen wie beispielsweise Standard-Spaltenwert, Nullfähigkeit für Spalten, Zeichensatz usw. werden jedoch nicht unterstützt.

  • Wenn Sie für partitionierte Tabellen in der Quelle den Vorbereitungsmodus Zieltabelle auf Tabellen auf Ziel löschen setzen, AWS DMS wird eine einfache Tabelle ohne Partitionen auf dem MySQL-Ziel erstellt. Wenn Sie partitionierte Tabellen in eine partitionierte Tabelle auf dem Ziel migrieren möchten, erstellen Sie zunächst die partitionierten Tabellen in der MySQL-Zieldatenbank.

  • Die Verwendung einer ALTER TABLE table_name ADD COLUMN column_name Anweisung zum Hinzufügen von Spalten am Anfang (FIRST) oder in der Mitte einer Tabelle (AFTER) wird für relationale Ziele nicht unterstützt. Spalten werden stets am Ende der Tabelle hinzugefügt. Wenn das Ziel Amazon S3 oder Amazon Kinesis Data Streams ist, wird das Hinzufügen von Spalten mit FIRST oder AFTER unterstützt.

  • CDC wird nicht unterstützt, wenn ein Tabellenname Groß- und Kleinbuchstaben enthält und die Quell-Engine auf einem Betriebssystem mit Dateinamen ohne Berücksichtigung von Groß-/Kleinschreibung gehostet wird. Ein Beispiel dafür ist Microsoft Windows oder OS X mit HFS+.

  • Sie können Aurora MySQL-Compatible Edition Serverless v1 für Volllast verwenden, aber Sie können es nicht für CDC verwenden. Dies liegt daran, dass Sie die Voraussetzungen für MySQL nicht aktivieren können. Weitere Informationen finden Sie unter Parameter groups and Aurora Serverless v1.

    Aurora MySQL-Compatible Edition Serverless v2 unterstützt CDC.

  • Das Attribut AUTO_INCREMENT auf einer Spalte wird nicht zu einer Spalte in der Zieldatenbank migriert.

  • Das Erfassen von Änderungen, wenn die Binärprotokolle nicht auf Standardblockspeicher gespeichert sind, wird nicht unterstützt. Beispiel: CDC funktioniert nicht, wenn die Binärprotokolle auf Amazon S3 gespeichert werden.

  • AWS DMS erstellt standardmäßig Zieltabellen mit der InnoDB-Speicher-Engine. Falls Sie eine andere Speicher-Engine als InnoDB benötigen, müssen Sie die Tabelle manuell erstellen und dann die Daten mit dem Modus do nothing migrieren.

  • Sie können Aurora MySQL-Repliken nicht als Quelle für verwenden, AWS DMS es sei denn, Ihr DMS-Migrations-Taskmodus lautet „Vorhandene Daten migrieren — nur Volllast“.

  • Wenn die MySQL-compatible Quelle während des Vollladens gestoppt wird, wird die AWS DMS Aufgabe nicht mit einem Fehler beendet. Die Aufgabe wird erfolgreich abgeschlossen, aber das Ziel wurde möglicherweise nicht mit der Quelle synchronisiert. Wenn dies geschieht, starten Sie entweder die Aufgabe neu oder Sie laden die betroffenen Tabellen neu.

  • Indizes, die auf einem Teil des Spaltenwerts erstellt wurden, werden nicht migriert. Beispielsweise wird der Index CREATE INDEX first_ten_chars ON customer (name(10)) nicht auf dem Ziel erstellt.

  • In einigen Fällen ist die Aufgabe so konfiguriert, dass sie keine LOBs repliziert (“ SupportLobs "ist in den Aufgabeneinstellungen falsch oder LOB-Spalten nicht einbeziehen ist in der Task-Konsole ausgewählt). In diesen Fällen migriert AWS DMS keine MEDIUMBLOB-, LONGBLOB-, MEDIUMTEXT- und LONGTEXT-Spalten zum Ziel.

    Spalten des Typs BLOB, TINYBLOB, TEXT und TINYTEXT sind davon nicht betroffen und werden zum Ziel migriert.

  • Temporäre Datentabellen oder systemversionierte Tabellen werden in MariaDB-Quell- und Zieldatenbanken nicht unterstützt.

  • Bei der Migration zwischen zwei Amazon RDS Aurora MySQL-Clustern muss der RDS Aurora MySQL-Quellendpunkt eine Instance sein, keine Replica-Instance. read/write

  • AWS DMS unterstützt derzeit keine Views-Migration für MariaDB.

  • AWS DMS unterstützt keine DDL-Änderungen für partitionierte Tabellen für MySQL. Setzen Sie skipTableSuspensionForPartitionDdl auf true, um das Sperren von Tabellen bei DDL-Änderungen an Partitionen während CDC zu überspringen.

  • AWS DMS unterstützt nur XA-Transaktionen in Version 3.5.0 und höher. Frühere Versionen unterstützen keine XA-Transaktionen. AWS DMS unterstützt keine XA-Transaktionen in MariaDB-Version 10.6 oder höher. Weitere Informationen finden Sie im Folgenden. Unterstützung für XA-Transaktionen

  • AWS DMS verwendet keine GTIDs für die Replikation, auch wenn die Quelldaten sie enthalten.

  • AWS DMS unterstützt das erweiterte Aurora MySQL-Binärprotokoll nicht.

  • AWS DMS unterstützt keine binäre Log-Transaktionskomprimierung.

  • AWS DMS gibt die Ereignisse ON DELETE CASCADE und ON UPDATE CASCADE für MySQL-Datenbanken mithilfe der InnoDB-Speicher-Engine nicht weiter. Für diese Ereignisse generiert MySQL keine Binlog-Ereignisse, um die kaskadierten Operationen in den untergeordneten Tabellen widerzuspiegeln. Folglich AWS DMS können die entsprechenden Änderungen an den untergeordneten Tabellen nicht repliziert werden. Weitere Informationen finden Sie unter Indizes, Fremdschlüssel oder kaskadierende Aktualisierungen oder Löschungen wurden nicht migriert.

  • AWS DMS erfasst keine Änderungen an berechneten (VIRTUALundGENERATED ALWAYS) Spalten. Gehen Sie wie folgt vor, um diese Einschränkung zu umgehen:

    • Pre-create die Zieltabelle in der Zieldatenbank und erstellt die AWS DMS Aufgabe mit der Einstellung DO_NOTHING oder TRUNCATE_BEFORE_LOAD Volllast.

    • Fügen Sie eine Transformationsregel hinzu, um die berechnete Spalte aus dem Aufgabenbereich zu entfernen. Informationen zu Transformationsregeln finden Sie unter Transformationsregeln und Aktionen.

  • Aufgrund interner MySQL-Beschränkungen AWS DMS können BinLogs verarbeitet werden, die nicht größer als 4 GB sind. BinLogs, die größer als 4 GB sind, können zu Fehlschlägen bei der DMS-Aufgabe oder zu anderem unvorhersehbarem Verhalten führen. Sie müssen die Größe von Transaktionen reduzieren, um BinLogs zu vermeiden, die größer als 4 GB sind.

  • AWS DMS unterstützt keine Backticks (`) oder einfache Anführungszeichen (') in Schema-, Tabellen- und Spaltennamen.

  • AWS DMS migriert keine Daten aus unsichtbaren Spalten in Ihrer Quelldatenbank. Um diese Spalten in Ihren Migrationsumfang aufzunehmen, verwenden Sie die ALTER TABLE-Anweisung, um diese Spalten sichtbar zu machen.

Unterstützung für XA-Transaktionen

Eine Extended Architecture (XA)-Transaktion ist eine Transaktion, die verwendet werden kann, um eine Reihe von Operationen aus mehreren Transaktionsressourcen in einer einzigen, zuverlässigen globalen Transaktion zusammenzufassen. Eine XA-Transaktion verwendet ein zweiphasiges Commit-Protokoll. Im Allgemeinen kann die Erfassung von Änderungen während offener XA-Transaktionen zu Datenverlust führen. Wenn Ihre Datenbank keine XA-Transaktionen verwendet, können Sie diese Berechtigung und die Konfiguration ignorieren, IgnoreOpenXaTransactionsCheck indem Sie den Standardwert verwendenTRUE. Gehen Sie wie folgt vor, um mit der Replikation aus einer Quelle zu beginnen, die XA-Transaktionen enthält:

  • Stellen Sie sicher, dass der AWS DMS Endpunktbenutzer über die folgende Berechtigung verfügt:

    grant XA_RECOVER_ADMIN on *.* to 'userName'@'%';

  • Setzen Sie die Endpunkteinstellung IgnoreOpenXaTransactionsCheck auf false.

Anmerkung

AWS DMS unterstützt keine XA-Transaktionen auf MariaDB Source DB Version 10.6 oder höher.

Endpunkteinstellungen bei Verwendung von MySQL als Quelle für AWS DMS

Sie können Endpunkteinstellungen, ähnlich wie zusätzliche Verbindungsattribute, zum Konfigurieren Ihrer MySQL-Quelldatenbank verwenden. Sie geben die Einstellungen an, wenn Sie den Quellendpunkt mithilfe der AWS DMS Konsole erstellen, oder indem Sie den create-endpoint Befehl in der AWS CLI mit der --my-sql-settings '{"EndpointSetting": "value", ...}' JSON-Syntax verwenden.

Die folgende Tabelle zeigt die Endpunkteinstellungen, die Sie mit MySQL als Quelle verwenden können.

Name Description

ConnectionTimeout

Verwenden Sie dieses zusätzliche Verbindungsattribut (ECA), um das Endpunkt-Verbindungstimeout für die MySQL-Instance in Sekunden festzulegen. Der Standardwert liegt bei 10 Sekunden. ECA-Beispiel:ConnectionTimeout=30.
EventsPollInterval

Gibt an, wie oft das Binärlog auf Neues überprüft werden soll changes/events, wenn die Datenbank inaktiv ist.

Standardwert: 5

Zulässige Werte: 1 bis 60

Beispiel: --my-sql-settings '{"EventsPollInterval": 5}'

Im Beispiel werden die Binärprotokolle alle fünf Sekunden auf Änderungen AWS DMS überprüft.
ExecuteTimeout

Legt für AWS DMS Versionen 3.4.7 und höher den Timeout der Client-Anweisung für einen MySQL-Quellendpunkt in Sekunden fest.

Standardwert: 60

Beispiel: --my-sql-settings '{"ExecuteTimeout": 1500}'
ServerTimezone

Gibt die Zeitzone für die MySQL-Quelldatenbank an.

Beispiel: --my-sql-settings '{"ServerTimezone": "US/Pacific"}'
AfterConnectScript

Gibt ein Skript an, das unmittelbar nach dem Herstellen einer AWS DMS Verbindung zum Endpunkt ausgeführt werden soll. Die Migrationsaufgabe wird weiter ausgeführt, unabhängig davon, ob die SQL-Anweisung erfolgreich ist oder fehlschlägt.

Zulässige Werte: Eine oder mehrere gültige SQL-Anweisungen, getrennt durch ein Semikolon.

Beispiel: --my-sql-settings '{"AfterConnectScript": "ALTER SESSION SET CURRENT_SCHEMA=system"}'
CleanSourceMetadataOnMismatch

Bereinigt und erstellt Tabellenmetadaten-Informationen auf der Replikations-Instance, wenn eine fehlende Übereinstimmung auftritt. Zum Beispiel in einer Situation, in der das Ausführen einer alter DDL auf der Tabelle zu unterschiedlichen Informationen über die in der Replikations-Instance zwischengespeicherte Tabelle führen könnte. Boolesch.

Standardwert: false

Beispiel: --my-sql-settings '{"CleanSourceMetadataOnMismatch": false}'
skipTableSuspensionForPartitionDdl

AWS DMS unterstützt keine DDL-Änderungen für partitionierte Tabellen für MySQL. Bei AWS DMS Versionen 3.4.6 und höher wird durch die Einstellung dieser Einstellung die Tabellensusperrung aufgrund von true Partitions-DDL-Änderungen während CDC übersprungen. AWS DMS ignoriert DDL, die sich auf partitionierte Tabellen bezieht, und verarbeitet weitere Änderungen am Binärlog weiter.

Standardwert: false

Beispiel: --my-sql-settings '{"skipTableSuspensionForPartitionDdl": true}'
IgnoreOpenXaTransactionsCheck

Gibt für AWS DMS Versionen 3.5.0 und höher an, ob Aufgaben offene XA-Transaktionen beim Start ignorieren sollen. Setzen Sie dies auf false, wenn Ihre Quelle XA-Transaktionen enthält.

Standardwert: true

Beispiel: --my-sql-settings '{"IgnoreOpenXaTransactionsCheck": false}'

Quelldatentypen für MySQL

Die folgende Tabelle zeigt die Datentypen der MySQL-Datenbankquelle, die bei der Verwendung von Datentypen unterstützt werden, AWS DMS sowie die Standardzuordnung von AWS DMS Datentypen.

Weitere Informationen zum Anzeigen des Datentyps, der im Ziel zugewiesen ist, finden Sie im Abschnitt für den Zielendpunkt, den Sie verwenden.

Weitere Hinweise zu AWS DMS Datentypen finden Sie unterDatentypen für den AWS Database Migration Service.

MySQL-Datentypen

AWS DMS Datentypen

INT

INT4

BIGINT

INT8

MEDIUMINT

INT4

TINYINT

INT1

SMALLINT

INT2

UNSIGNED TINYINT

UINT1

UNSIGNED SMALLINT

UINT2

UNSIGNED MEDIUMINT

UINT4

UNSIGNED INT

UINT4

UNSIGNED BIGINT

UINT8

DECIMAL(10)

NUMERIC (10,0)

BINARY

BYTES(1)

BIT

BOOLEAN

BIT(64)

BYTES(8)

BLOB

BYTES(65535)

LONGBLOB

BLOB

MEDIUMBLOB

BLOB

TINYBLOB

BYTES(255)

DATE

DATE

DATETIME

DATETIME

DATETIME ohne einen Wert in Klammern wird ohne Millisekunden repliziert. DATETIME mit einem Wert zwischen 1 und 5 in Klammern (z. B. DATETIME(5)) wird mit Millisekunden repliziert.

Bei der Replikation einer DATETIME-Spalte bleibt die Uhrzeit im Ziel gleich. Sie wird nicht in UTC konvertiert.

TIME

STRING

TIMESTAMP (ZEITSTEMPEL)

DATETIME

Bei der Replikation einer TIMESTAMP-Spalte wird die Uhrzeit im Ziel in UTC konvertiert.

JAHR

INT2

DOUBLE

REAL8

FLOAT

REAL(DOUBLE)

Wenn die FLOAT-Werte nicht im folgenden Bereich liegen, verwenden Sie eine Transformation, um FLOAT auf STRING abzubilden. Weitere Informationen zu Umwandlungen finden Sie unter Transformationsregeln und Aktionen.

Der unterstützte FLOAT-Bereich liegt zwischen -1,79E+308 und -2,23, 0 und 2,23 E-308 bis 1,79E+308 E-308

VARCHAR (45)

WSTRING (45)

VARCHAR (2000)

WSTRING (2000)

VARCHAR (4000)

WSTRING (4000)

VARBINARY (4000)

BYTES (4000)

VARBINARY (2000)

BYTES (2000)

CHAR

WSTRING

TEXT

WSTRING

LONGTEXT

NCLOB

MEDIUMTEXT

NCLOB

TINYTEXT

WSTRING(255)

GEOMETRY

BLOB

POINT

BLOB

LINESTRING

BLOB

POLYGON

BLOB

MULTIPOINT

BLOB

MULTILINESTRING

BLOB

MULTIPOLYGON

BLOB

GEOMETRYCOLLECTION

BLOB

ENUM

lengthZEICHENFOLGE ()

Hier length ist die Länge des längsten Werts in der ENUM.

SET

ZEICHENFOLGE () length

Hier length ist die Gesamtlänge aller Werte im SET, einschließlich Kommas.

JSON

CLOB
Anmerkung

In einigen Fällen können Sie die Datentypen DATETIME und TIMESTAMP mit einem „Null“-Wert (d. h. 0000-00-00) angeben. Stellen Sie in diesem Fall sicher, dass die Zieldatenbank in der Replikationsaufgabe „Null“-Werte für die Datentypen DATETIME und TIMESTAMP unterstützt. Andernfalls werden diese Werte als "null" im Ziel erfasst.