View a markdown version of this page

Verwenden einer MySQL-compatible Datenbank als Ziel für AWS Database Migration Service - AWS Database Migration Service
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 mit AWS DMS jeder der AWS DMS unterstützten Quell-Daten-Engines in jede MySQL-compatible Datenbank migrieren. Wenn Sie zu einer lokalen MySQL-compatible Datenbank migrieren, AWS DMS setzt dies voraus, dass sich Ihre Quell-Engine innerhalb des Ökosystems befindet. AWS Die Engine kann sich in einem AWS verwalteten Service 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ützen, 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 Quell-Speicher-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 auf dem MySQL-compatible Ziel manuell erstellen und die Tabelle mit der Option Nichts tun migrieren. Weitere Informationen finden Sie unter Full-load Task-Einstellungen.

Weitere Informationen zur Arbeit 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 mit der Arbeit mit einer MySQL-compatible Datenbank als Ziel für beginnen AWS DMS, stellen Sie sicher, dass Sie die folgenden Voraussetzungen erfüllt haben:

  • Geben Sie ein Benutzerkonto an AWS DMS , das über read/write Rechte 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 Fremdschlüsselprüfungen in einer MySQL-compatible Datenbank während eines vollen 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 Rechte, wenn Sie Bewertungen 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. Lesen 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 Keine gesetzt ist, werden Verbindungen abgelehnt. Wenn Ihr Endpunkt-SSL-Modus auf None 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. Alternativ können Sie OFF in Ihrer Aurora-Cluster-Parametergruppe auf einstellenrequire_secure_transport, 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 diese 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 nicht für MySQL-Endpunkte. Dies hat keine Auswirkungen 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 ist. *: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 Masterbenutzer-Passwort wurde zurückgesetzt

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

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 *:mysql_native_password in Ihrer Cluster-Parametergruppe auf 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 von Aurora MySQL 8.4 finden Sie unter Sicherheit mit Amazon Aurora MySQL und Passwortverwaltung mit Amazon Aurora und Secrets Manager im Amazon Aurora 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, unterstützt Folgendes AWS DMS nicht:

  • 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

  • Beim Laden von Daten in ein MySQL-compatible Ziel im Rahmen einer Vollladeaufgabe werden AWS DMS keine Fehler gemeldet, die durch Einschränkungen in den Aufgabenprotokollen verursacht werden. Dies kann zu doppelten Schlüsselfehlern oder Nichtübereinstimmungen mit 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

    • Stellen Sie mithilfe der AWS DMS Validierung sicher, 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 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 Schreibmodus, d. h. die innodb_read_only Parameter read_only und sind auf 0 oder OFF gesetzt. 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 dem zusätzlichen Verbindungsattribut ist der Zeitwert auf den 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 ähnlich wie bei der Verwendung zusätzlicher Verbindungsattribute zu konfigurieren. Sie geben die Einstellungen an, wenn Sie den Zielendpunkt mithilfe der AWS DMS Konsole oder mithilfe des create-endpoint Befehls in der mit der AWS CLI--my-sql-settings '{"EndpointSetting": "value", ...}'JSON-Syntax erstellen.

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 Endpunktverbindungstimeout 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 verwendet werden sollen, um die Daten in die MySQL-compatible Zieldatenbank zu laden. 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, den standardmäßigen kompilierten Zeichensatz der Datenbank. 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) jeder 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 Zieldatentypen der MySQL-Datenbank, die bei der Verwendung unterstützt werden, AWS DMS und die Standardzuweisung 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).