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.

# Verwendung einer MySQL-compatible Datenbank als Quelle für AWS DMS
<a name="CHAP_Source.MySQL"></a>

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](CHAP_Introduction.Sources.md). 

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 unter[Verwenden von SSL mit AWS Database Migration Service](CHAP_Security.SSL.md).

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 zur Arbeit mit MySQL-compatible Datenbanken und AWS DMS finden Sie in den folgenden Abschnitten.

**Topics**
+ [Migration von MySQL zu MySQL mit AWS DMS](#CHAP_Source.MySQL.Homogeneous)
+ [Verwenden Sie eine beliebige MySQL-compatible Datenbank als Quelle für AWS DMS](#CHAP_Source.MySQL.Prerequisites)
+ [Verwendung einer selbstverwalteten MySQL-compatible Datenbank als Quelle für AWS DMS](#CHAP_Source.MySQL.CustomerManaged)
+ [Verwenden eines AWS-verwaltete MySQL-compatible Datenbank als Quelle für AWS DMS](#CHAP_Source.MySQL.AmazonManaged)
+ [Überlegungen zu Aurora MySQL 8.4-Quellen](#CHAP_Source.MySQL.AuroraMySQL84)
+ [Einschränkungen bei der Verwendung einer MySQL-Datenbank als Quelle für AWS DMS](#CHAP_Source.MySQL.Limitations)
+ [Unterstützung für XA-Transaktionen](#CHAP_Source.MySQL.XA)
+ [Endpunkteinstellungen bei Verwendung von MySQL als Quelle für AWS DMS](#CHAP_Source.MySQL.ConnectionAttrib)
+ [Quelldatentypen für MySQL](#CHAP_Source.MySQL.DataTypes)

**Anmerkung**  
Bei der Konfiguration von AWS Database Migration Service (AWS DMS) -Zuordnungsregeln ist es wichtig, Platzhalter (%) 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 erforderlich sind. Da der MySQL Amazon RDS-Mastbenutzer nicht über die erforderlichen Berechtigungen verfügt, um Daten in Zielsystemdatenbanken zu importieren, schlägt der Versuch fehl, diese Systemdatenbanken zu migrieren.

## Migration von MySQL zu MySQL mit AWS DMS
<a name="CHAP_Source.MySQL.Homogeneous"></a>

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 Sie eine beliebige MySQL-compatible Datenbank als Quelle für AWS DMS
<a name="CHAP_Source.MySQL.Prerequisites"></a>

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 verfügen AWS DMS , das die Rolle des Replikationsadministrators innehat. 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 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
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 Tests MySQL-specific vor der Migration durchführen möchten, fügen Sie die folgende Berechtigung hinzu:

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

Wenn der Parameter „`BatchEnable``true`ist“, muss Folgendes gewährt werden:

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

## Verwendung einer selbstverwalteten MySQL-compatible Datenbank als Quelle für AWS DMS
<a name="CHAP_Source.MySQL.CustomerManaged"></a>

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`<br />oder<br />`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, die in MySQL 8.4 seit 8.0 hinzugefügt, veraltet oder entfernt wurden](https://dev.mysql.com/doc/refman/8.4/en/added-deprecated-removed.html#optvars-removed).<br />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](https://dev.mysql.com/doc/refman/5.7/en/replication-options-binary-log.html#sysvar_expire_logs_days).<br />Verwenden Sie den `binlog_expire_logs_seconds` Parameter für MySQL 8.0 und höher. Wir empfehlen, dass Sie diesen Parameter auf einen Wert von `86400` Sekunden (1 Tag) oder mehr setzen. Siehe [Optionen und Variablen für die binäre Protokollierung](https://dev.mysql.com/doc/refman/8.0/en/replication-options-binary-log.html#sysvar_binlog_expire_logs_seconds). | 
| `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 im Modus **Vorhandene Daten migrieren und laufende Änderungen replizieren** verwenden, besteht die Möglichkeit eines Datenverlusts. Unter den folgenden Bedingungen schreibt DMS weder bei Volllast noch bei CDC eine Transaktion:
+ Die Transaktion wurde vor dem Start der DMS-Aufgabe für die primäre Instanz festgeschrieben.
+ Die Transaktion wurde aufgrund der Verzögerung zwischen der primären Instanz 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 Instanz und dem Replikat ist, desto größer ist die Gefahr 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. | 

## Verwenden eines AWS-verwaltete MySQL-compatible Datenbank als Quelle für AWS DMS
<a name="CHAP_Source.MySQL.AmazonManaged"></a>

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 MySQL-Compatible Aurora-Ausgabe

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](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_WorkingWithAutomatedBackups.html) 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](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_LogAccess.MySQL.BinaryFormat.html) 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?](https://aws.amazon.com/premiumsupport/knowledge-center/enable-binary-logging-aurora/). 
+ 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](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_LogAccess.MySQL.BinaryFormat.html) im *Benutzerhandbuch für Amazon RDS*.
+ Stellen Sie sicher, dass die Binärprotokolle für verfügbar sind. AWS DMS Da mit AWS-managed MySQL-compatible databases die Binärprotokolle so schnell wie möglich gelöscht werden, sollten Sie den Zeitraum erhöhen, für den 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. Dadurch wird möglicherweise AWS DMS verhindert, 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 `"NONE"` für DMS-Version 3.4.7 oder früher auf. Weitere Informationen zum Festlegen von Parametern in Amazon RDS MySQL finden Sie unter [Working with automated backups](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_WorkingWithAutomatedBackups.html) 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 von Aurora MySQL 8.4 finden Sie unter [Sicherheit mit Amazon Aurora MySQL](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Security.html) und [Passwortverwaltung mit Amazon Aurora und Secrets Manager](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/rds-secrets-manager.html) im *Amazon Aurora Aurora-Benutzerhandbuch*.

## Überlegungen zu Aurora MySQL 8.4-Quellen
<a name="CHAP_Source.MySQL.AuroraMySQL84"></a>

Aurora MySQL 8.4 führt Sicherheitsänderungen ein, die sich auf die Konnektivität der AWS DMS Quellendpunkte auswirken können. Lesen 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 **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 einstellen`require_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 durch`authentication_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 Quellendpunkt das Hauptbenutzerkonto verwendet, überprüfen Sie die Konnektivität nach dem 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';`

## Einschränkungen bei der Verwendung einer MySQL-Datenbank als Quelle für AWS DMS
<a name="CHAP_Source.MySQL.Limitations"></a>

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 auf der Quelle den **Target-Tabellenvorbereitungsmodus** 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](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-serverless.how-it-works.html#aurora-serverless.parameter-groups). 

  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](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_GettingStarted.html) migrieren.
+ Sie können Aurora MySQL-Repliken nicht als Quelle verwenden, AWS DMS es sei denn, Ihr DMS-Migrationsaufgabenmodus lautet **Vorhandene Daten migrieren** — nur Volllast.
+  Wenn die MySQL-compatible Quelle bei Volllast 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 LOBs nicht repliziert werden (“ SupportLobs "ist in den Aufgabeneinstellungen falsch oder in der Task-Konsole wurde die **Option LOB-Spalten nicht einbeziehen** 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 es sich beim RDS Aurora MySQL-Quellendpunkt um eine read/write Instance und nicht um eine Replikat-Instance handeln. 
+ AWS DMS unterstützt derzeit keine Migration von Ansichten 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](#CHAP_Source.MySQL.XA)
+ AWS DMS verwendet keine GTIDs für die Replikation, auch wenn die Quelldaten sie enthalten. 
+ AWS DMS unterstützt das erweiterte Binärprotokoll von Aurora MySQL nicht.
+ AWS DMS unterstützt keine Komprimierung von binären Protokolltransaktionen.
+ AWS DMS verbreitet die Ereignisse ON DELETE CASCADE und ON UPDATE CASCADE nicht für MySQL-Datenbanken unter Verwendung der InnoDB-Speicher-Engine. 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 nicht in die untergeordneten Tabellen repliziert werden. Weitere Informationen finden Sie unter [Indizes, Fremdschlüssel oder kaskadierende Aktualisierungen oder Löschungen wurden nicht migriert](CHAP_Troubleshooting.md#CHAP_Troubleshooting.MySQL.FKsAndIndexes).
+ AWS DMS erfasst keine Änderungen an berechneten (`VIRTUAL`und`GENERATED ALWAYS`) Spalten. Gehen Sie wie folgt vor, um diese Einschränkung zu umgehen:
  + Pre-create die Zieltabelle in der Zieldatenbank und erstellen Sie die AWS DMS Aufgabe mit der Aufgabeneinstellung `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](CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Transformations.md).
+ Aufgrund interner MySQL-Einschränkungen AWS DMS können BinLogs mit einer Größe von nicht mehr als 4 GB verarbeitet werden. BinLogs, die größer als 4 GB sind, können zu Fehlern bei DMS-Aufgaben oder zu anderem unvorhersehbarem Verhalten führen. Sie müssen die Größe der 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 Migrationsbereich aufzunehmen, verwenden Sie die ALTER TABLE-Anweisung, um diese Spalten sichtbar zu machen.

## Unterstützung für XA-Transaktionen
<a name="CHAP_Source.MySQL.XA"></a>

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 verwenden. `TRUE` 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 folgenden Rechte 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
<a name="CHAP_Source.MySQL.ConnectionAttrib"></a>

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 oder mithilfe des `create-endpoint` Befehls in [AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/dms/index.html), mit der `--my-sql-settings '{"{{EndpointSetting"}}: {{"value"}}, {{...}}}'` JSON-Syntax erstellen.

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 Endpunktverbindungstimeout 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 neue Daten überprüft werden soll changes/events, wenn sich die Datenbank im Leerlauf befindet. <br />Standardwert: 5 <br />Zulässige Werte: 1 bis 60 <br />Beispiel: `--my-sql-settings '{"EventsPollInterval": 5}'`<br />In diesem Beispiel wird AWS DMS alle fünf Sekunden nach Änderungen in den Binärprotokollen gesucht. | 
| 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.<br />Standardwert: 60 <br />Beispiel: `--my-sql-settings '{"ExecuteTimeout": 1500}'` | 
| ServerTimezone | Gibt die Zeitzone für die MySQL-Quelldatenbank an.<br />Beispiel: `--my-sql-settings '{"ServerTimezone": "{{US/Pacific}}"}'` | 
| AfterConnectScript | Gibt ein Skript an, das unmittelbar nach der AWS DMS Verbindung mit dem Endpunkt ausgeführt werden soll. Die Migrationsaufgabe wird weiter ausgeführt, unabhängig davon, ob die SQL-Anweisung erfolgreich ist oder fehlschlägt. <br />Zulässige Werte: Eine oder mehrere gültige SQL-Anweisungen, getrennt durch ein Semikolon. <br />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.<br />Standardwert: `false`<br />Beispiel: `--my-sql-settings '{"CleanSourceMetadataOnMismatch": false}'` | 
|  skipTableSuspensionForPartitionDdl  | AWS DMS unterstützt keine DDL-Änderungen für partitionierte Tabellen für MySQL. Bei den AWS DMS Versionen 3.4.6 und höher wird bei der Einstellung dieser Einstellung die Tabellensperre bei `true` DDL-Änderungen an Partitionen während CDC übersprungen. AWS DMS ignoriert DDL, die sich auf partitionierte Tabellen beziehen, und verarbeitet weitere Änderungen im Binärprotokoll weiter. <br />Standardwert: `false`<br />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.<br />Standardwert: `true`<br />Beispiel: `--my-sql-settings '{"IgnoreOpenXaTransactionsCheck": false}'` | 

## Quelldatentypen für MySQL
<a name="CHAP_Source.MySQL.DataTypes"></a>

Die folgende Tabelle zeigt die Quelldatentypen der MySQL-Datenbank, die bei der Verwendung unterstützt werden, AWS DMS sowie die Standardzuweisung 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 unter[Datentypen für den AWS Database Migration Service](CHAP_Reference.DataTypes.md).


|  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<br />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.<br />Bei der Replikation einer DATETIME-Spalte bleibt die Uhrzeit im Ziel gleich. Sie wird nicht in UTC konvertiert. | 
| TIME | STRING | 
| TIMESTAMP (ZEITSTEMPEL) | DATETIME<br />Bei der Replikation einer TIMESTAMP-Spalte wird die Uhrzeit im Ziel in UTC konvertiert. | 
| JAHR | INT2 | 
| DOUBLE | REAL8 | 
| FLOAT | REAL(DOUBLE)<br />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](CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Transformations.md).<br />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 | {{length}}ZEICHENFOLGE ()<br />Hier {{length}} ist die Länge des längsten Werts in der ENUM-Datei. | 
| SET | ZEICHENFOLGE () {{length}}<br />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.