View a markdown version of this page

Verwenden einer MySQL-compatible Datenbank als Ziel für AWS Database Migration Service - AWS Datenbankmigrationsdienst
Voraussetzungen für MySQL als ZielAurora MySQL 8.4-ZieleEinschränkungen für MySQL als ZielEndpunkteinstellungenZieldatentypen 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 Ziel für AWS Database Migration Service

Sie können Daten in jede MySQL-compatible Datenbank migrieren AWS DMS, indem Sie jede der AWS DMS unterstützten Quell-Daten-Engines verwenden. Wenn Sie zu einer lokalen MySQL-compatible Datenbank migrieren, AWS DMS muss sich Ihre Quell-Engine innerhalb des Ökosystems befinden. AWS Die Engine kann sich auf einem AWS verwalteten Dienst wie Amazon RDS, Amazon Aurora oder Amazon S3 befinden. Alternativ kann sich die Engine in einer selbstverwalteten Datenbank auf Amazon EC2 befinden.

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.

Hinweise zu Versionen von MySQL, die als Ziel AWS DMS unterstützt werden, finden Sie unterZiele für AWS DMS.

Sie können die folgenden MySQL-compatible Datenbanken als Ziele verwenden für 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

  • Amazon Aurora MySQL

Anmerkung

Unabhängig von der Quellspeicher-Engine (MyISAM, MEMORY usw.) wird standardmäßig eine MySQL-compatible Zieltabelle als InnoDB-Tabelle AWS DMS erstellt.

Wenn Sie eine Tabelle in einer anderen Speicher-Engine als InnoDB benötigen, können Sie die Tabelle manuell auf dem MySQL-compatible Ziel erstellen und die Tabelle mithilfe der Option Do nothing migrieren. Weitere Informationen finden Sie unter Full-load Task-Einstellungen.

Weitere Informationen zum Arbeiten mit einer MySQL-compatible Datenbank als Ziel für AWS DMS finden Sie in den folgenden Abschnitten.

Verwenden einer beliebigen MySQL-compatible Datenbank als Ziel für AWS Database Migration Service

Bevor Sie beginnen, mit einer MySQL-compatible Datenbank als Ziel für zu arbeiten AWS DMS, stellen Sie sicher, dass Sie die folgenden Voraussetzungen erfüllt haben:

  • Geben Sie ein Benutzerkonto an AWS DMS , das über read/write Berechtigungen für die MySQL-compatible Datenbank verfügt. Führen Sie die folgenden Befehle aus, um die erforderlichen Berechtigungen zu erstellen.

    
CREATE USER '<user acct>'@'%' IDENTIFIED BY '<user password>';
GRANT ALTER, CREATE, DROP, INDEX, INSERT, UPDATE, DELETE, SELECT, CREATE TEMPORARY TABLES  ON <schema>.* TO 
'<user acct>'@'%';
GRANT ALL PRIVILEGES ON awsdms_control.* TO '<user acct>'@'%';

  • Während der Volllast-Migrationsphase müssen Sie Fremdschlüssel in Ihren Zieltabellen deaktivieren. Um die Fremdschlüsselüberprüfung einer MySQL-compatible Datenbank während eines vollständigen Ladevorgangs zu deaktivieren, können Sie den folgenden Befehl zum Abschnitt Zusätzliche Verbindungsattribute der AWS DMS Konsole für Ihren Zielendpunkt hinzufügen.

    Initstmt=SET FOREIGN_KEY_CHECKS=0;

  • Legen Sie den Datenbankparameter local_infile = 1 fest, um AWS DMS das Laden von Daten in die Zieldatenbank zu ermöglichen.

  • 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

Überlegungen zu Aurora MySQL 8.4-Zielen

Aurora MySQL 8.4 führt Sicherheitsänderungen ein, die sich auf die Konnektivität der AWS DMS Zielendpunkte auswirken können. Überprüfen Sie Folgendes, bevor Sie Ihr Aurora MySQL-Ziel 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 Zielendpunkt eine Verbindung zu Aurora MySQL 8.4 herstellt und der SSL-Modus auf „None“ gesetzt ist, werden Verbindungen abgelehnt. Wenn der SSL-Modus Ihres Endpunkts 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 nach dem Upgrade ihr aktuelles Authentifizierungs-Plugin. 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 Zielendpunkt 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';

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. Informationen zu bekannten Problemen mit dem Authentifizierungs-Plugin finden Sie unter Authentifizierungs-Plugin im Amazon RDS-Benutzerhandbuch.

Einschränkungen bei der Verwendung einer MySQL-compatible Datenbank als Ziel für AWS Database Migration Service

Wenn Sie eine MySQL-Datenbank als Ziel verwenden, wird Folgendes AWS DMS nicht unterstützt:

  • Die DDL-Anweisungen (Data Definition Language) TRUNCATE PARTITION, DROP TABLE und RENAME TABLE.

  • Verwenden einer ALTER TABLE table_name ADD COLUMN column_name-Anweisung zum Hinzufügen von Spalten an den Anfang oder in die Mitte einer Tabelle

  • Meldet beim Laden von Daten in ein MySQL-compatible Ziel in einer Vollladeaufgabe AWS DMS keine Fehler, die durch Einschränkungen in den Aufgabenprotokollen verursacht werden. Dies kann zu doppelten Schlüsselfehlern oder Abweichungen von der Anzahl der Datensätze führen. Dies ist auf die Art und Weise zurückzuführen, wie MySQL lokale Daten mit dem Befehl LOAD DATA behandelt. Während der Volllastphase müssen Sie folgende Schritte ausführen:

    • Einschränkungen deaktivieren

    • Verwenden Sie die AWS DMS Validierung, um sicherzustellen, dass die Daten konsistent sind.

  • Wenn Sie den Wert einer Spalte auf den vorhandenen Wert aktualisieren, geben MySQL-compatible Datenbanken eine 0 rows affected Warnung zurück. Obwohl dieses Verhalten technisch gesehen kein Fehler ist, unterscheidet es sich von der Art und Weise, wie andere Datenbank-Engines mit solchen Fällen umgehen. Oracle führt beispielsweise eine Aktualisierung einer Zeile durch. AWS DMS Generiert für MySQL-compatible Datenbanken einen Eintrag in der Steuertabelle awsdms_apply_exceptions und protokolliert die folgende Warnung.

    
Some changes from the source database had no impact when applied to
the target database. See awsdms_apply_exceptions table for details.

  • Aurora Serverless ist als Ziel für Amazon Aurora Version 2, kompatibel mit MySQL Version 5.7, verfügbar. (Wählen Sie Aurora-MySQL-Version 2.07.1 aus, um Aurora Serverless mit MySQL-5.7-Kompatibilität verwenden zu können.) Weitere Informationen zu Aurora Serverless finden Sie unter Using Aurora Serverless v2 im Amazon Aurora-Benutzerhandbuch.

  • AWS DMS unterstützt nicht die Verwendung eines Reader-Endpunkts für Aurora oder Amazon RDS, es sei denn, die Instances befinden sich im beschreibbaren Modus, d. h. die innodb_read_only Parameter read_only und sind auf oder gesetzt. 0 OFF Weitere Informationen zur Verwendung von Amazon RDS und Aurora als Ziele finden Sie in folgenden Themen:

  • Bei der Replikation des TIME-Datentyps wird der Bruchteil des Zeitwerts nicht repliziert.

  • Bei der Replikation des TIME-Datentyps mit zusätzlichem Verbindungsattribut wird der Zeitwert auf einen Bereich loadUsingCSV=false begrenzt. [00:00:00, 23:59:59]

Endpunkteinstellungen bei Verwendung einer MySQL-compatible Datenbank als Ziel für AWS DMS

Sie können Endpunkteinstellungen verwenden, um Ihre MySQL-compatible Zieldatenbank zu konfigurieren, ähnlich wie bei der Verwendung zusätzlicher Verbindungsattribute. Sie geben die Einstellungen an, wenn Sie den Zielendpunkt 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 Ziel verwenden können.

Name Description

ConnectionTimeout

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

TargetDbType

Gibt an, wo die Quelltabellen in der Zieldatenbank migriert werden, entweder in einer einzelnen Datenbank oder mehreren Datenbanken. Wenn Sie angebenSPECIFIC_DATABASE, müssen Sie den Datenbanknamen angeben, entweder wenn Sie den AWS CLI oder den verwenden AWS-Managementkonsole.

Standardwert: MULTIPLE_DATABASES

Zulässige Werte: {SPECIFIC_DATABASE, MULTIPLE_DATABASES}

Beispiel: --my-sql-settings '{"TargetDbType": "MULTIPLE_DATABASES"}'

ParallelLoadThreads

Verbessert die Leistung beim Laden von Daten in die MySQL-compatible Zieldatenbank. Gibt an, wie viele Threads zum Laden der Daten in die MySQL-compatible Zieldatenbank verwendet werden sollen. Das Festlegen einer großen Anzahl von Threads kann die Datenbankleistung beeinträchtigen, da für jeden Thread eine separate Verbindung erforderlich ist.

Standardwert: 1

Zulässige Werte: 1 bis 5

Beispiel: --my-sql-settings '{"ParallelLoadThreads": 1}'

AfterConnectScript

Gibt ein Skript an, das sofort ausgeführt wird, nachdem AWS DMS eine Verbindung mit dem Endpunkt hergestellt hat.

Sie können beispielsweise angeben, dass das MySQL-compatible Ziel empfangene Anweisungen in den Zeichensatz latin1 übersetzen soll, der der standardmäßige einkompilierte Zeichensatz der Datenbank ist. Dieser Parameter verbessert in der Regel die Leistung beim Umwandeln von UTF8-Clients.

Beispiel: --my-sql-settings '{"AfterConnectScript": "SET character_set_connection='latin1'"}'

MaxFileSize

Gibt die maximale Größe (in KB) einer CSV-Datei an, die zur Übertragung von Daten in eine Datenbank verwendet wird. MySQL-compatible

Standardwert: 32768 KB (32 MB)

Gültige Werte: 1 bis 1 048 576

--my-sql-settings '{"MaxFileSize": 512}'

Sie können auch zusätzliche Verbindungsattribute verwenden, um Ihre MySQL-compatible Zieldatenbank zu konfigurieren.

Die folgende Tabelle zeigt die zusätzlichen Verbindungsattribute, die Sie verwenden können, wenn MySQL das Ziel ist.

Name Description

Initstmt=SET FOREIGN_KEY_CHECKS=0;

Deaktiviert die Fremdschlüsselprüfungen.

Beispiel: --extra-connection-attributes "Initstmt=SET FOREIGN_KEY_CHECKS=0;"

Initstmt=SET time_zone

Gibt die Zeitzone für die MySQL-compatible Zieldatenbank an.

Standardwert: UTC

Gültige Werte: Die in der MySQL-Zieldatenbank verfügbaren Zeitzonennamen.

Beispiel: --extra-connection-attributes "Initstmt=SET time_zone=US/Pacific;"

Alternativ können Sie den Parameter AfterConnectScript des Befehls --my-sql-settings verwenden, um Fremdschlüsselprüfungen zu deaktivieren und die Zeitzone für Ihre Datenbank anzugeben.

Zieldatentypen für MySQL

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

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

AWS DMS Datentypen

MySQL-Datentypen

BOOLEAN

BOOLEAN

BYTES

Ist die Länge 1 bis 65.535, verwenden Sie VARBINARY (Länge).

Ist die Länge 65.536 bis 2.147.483.647, verwenden Sie LONGLOB.

DATE

DATE

TIME

TIME

TIMESTAMP (ZEITSTEMPEL)

Ist die Skalierung => 0 und =< 6, dann: DATETIME (Skalierung)

Ist die Skalierung => 7 und =< 9, dann: VARCHAR (37)

INT1

TINYINT

INT2

SMALLINT

INT4

INTEGER

INT8

BIGINT

NUMERIC

DECIMAL (p,s)

REAL4

FLOAT

REAL8

DOUBLE PRECISION

STRING

Ist die Länge 1 bis 21.845, verwenden Sie VARCHAR (Länge).

Ist die Länge 21.846 bis 2.147.483.647, verwenden Sie LONGTEXT.

UINT1

UNSIGNED TINYINT

UINT2

UNSIGNED SMALLINT

UINT4

UNSIGNED INTEGER

UINT8

UNSIGNED BIGINT

WSTRING

Ist die Länge 1 bis 32.767, verwenden Sie VARCHAR (Länge).

Ist die Länge 32.768 bis 2.147.483.647, verwenden Sie LONGTEXT.

BLOB

Ist die Länge 1 bis 65.535, verwenden Sie BLOB.

Ist die Länge 65.536 bis 2.147.483.647, verwenden Sie LONGBLOB.

Ist die Länge 0, verwenden Sie LONGBLOB (vollständige LOB-Unterstützung).

NCLOB

Ist die Länge 1 bis 65.535, verwenden Sie TEXT.

Ist die Länge 65.536 bis 2.147.483.647, verwenden Sie LONGTEXT mit ucs2 für CHARACTER SET.

Ist die Länge 0, verwenden Sie LONGTEXT (vollständige LOB-Unterstützung) mit ucs2 für CHARACTER SET.

CLOB

Ist die Länge 1 bis 65.535, verwenden Sie TEXT.

Ist die Länge 65.536 bis 2.147.483.647, verwenden Sie LONGTEXT.

Ist die Länge 0, verwenden Sie LONGTEXT (vollständige LOB-Unterstützung).