Verwenden einer MySQL-kompatiblen Datenbank als Quelle für AWS DMS - AWS Database Migration Service
Migrieren von MySQL auf MySQLVerwenden von MySQL als QuelleVerwenden einer selbstverwalteten MySQL-DB als Quelle AWS-managed MySQL als Quelle verwendenEinschrä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-kompatiblen Datenbank als Quelle für AWS DMS

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

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

Sie können mit SSL Verbindungen zwischen Ihrem MySQL-kompatiblen Endpunkt und der Replikations-Instance verschlüsseln. Weitere Informationen zur Verwendung von SSL mit einem MySQL-kompatiblen Endpunkt finden Sie unter Verwenden 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 zur Arbeit mit MySQL-kompatiblen Datenbanken und finden Sie in den AWS DMS folgenden Abschnitten.

Migrieren von MySQL auf 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.

Verwendung einer beliebigen MySQL-kompatiblen 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 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, für full-load-only Aufgaben ist dieses Recht nicht erforderlich.

  • REPLICATION SLAVE – Diese Berechtigung ist nur für CDC-Aufgaben erforderlich. Mit anderen Worten, für full-load-only Aufgaben ist dieses Privileg nicht erforderlich.

  • 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.

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

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

  • 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

Legen Sie diesen Parameter auf einen Wert von 1 oder größer fest. Um zu verhindern, dass zu viel Speicherplatz verwendet wird, empfehlen wir, nicht den Standardwert 0 zu verwenden.

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.

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.

Verwendung einer AWS-verwalteten MySQL-kompatiblen Datenbank als Quelle für AWS DMS

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

  • MySQL Community Edition

  • MariaDB Community Edition

  • Amazon Aurora MySQL-Compatible Edition

Wenn Sie eine von AWS-managed MySQL-kompatible 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-managed MySQL-kompatible Datenbanken die Binärprotokolle so schnell wie möglich löschen, sollten Sie die Dauer erhöhen, für die 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 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.

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 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 der Anweisung ALTER TABLE table_name ADD COLUMN column_name zum Hinzufügen von Spalten zum Anfang (FIRST) oder zur Mitte einer Tabelle (AFTER) wird nicht unterstützt. Spalten werden stets am Ende der Tabelle hinzugefügt.

  • 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 sie 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. Beispielsweise funktioniert CDC nicht, wenn die Binärprotokolle in 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 verwenden, AWS DMS es sei denn, Ihr DMS-Migrationsaufgabenmodus lautet Vorhandene Daten migrieren — nur Volllast.

  • Im Falle, dass die MySQL-kompatible Quelle während des vollständigen Ladevorgangs gestoppt wird, bricht die AWS DMS -Aufgabe nicht mit einem Fehler ab. 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 LOB-Spalten nicht einbeziehen ist in der Task-Konsole ausgewählt). In diesen Fällen werden AWS DMS keine MEDIUMBLOB-, LONGBLOB-, MEDIUMTEXT- und LONGTEXT-Spalten zum Ziel migriert.

    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 Clustern von Amazon RDS Aurora MySQL muss es sich beim Quellendpunkt von RDS Aurora MySQL um eine Lese-/Schreib-Instance handeln, nicht um eine Replikat-Instance.

  • 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. Weitere Informationen finden Sie unter 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 keine Komprimierung von binären Protokolltransaktionen.

  • AWS DMS verbreitet die Ereignisse ON DELETE CASCADE und ON UPDATE CASCADE nicht für MySQL-Datenbanken, die die InnoDB-Speicher-Engine verwenden. 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.

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

    • Erstellen Sie die Zieltabelle vorab in der Zieldatenbank und erstellen Sie die AWS DMS -Aufgabe mit der Einstellung DO_NOTHING oder TRUNCATE_BEFORE_LOAD für Aufgaben mit vollständigem Laden.

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

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 IgnoreOpenXaTransactionsCheck ignorieren, indem Sie den Standardwert TRUE verwenden. 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 Berechtigungen 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.

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 oder mithilfe des create-endpoint Befehls in AWS CLI, 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 Beschreibung
EventsPollInterval

Gibt an, wie oft das binäre Protokolle für neue Änderungen/Ereignisse überprüft wird, wenn die Datenbank inaktiv ist.

Standardwert: 5

Zulässige Werte: 1 bis 60

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

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.

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 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.

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"}'
CleanSrcMetadataOnMismatch

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 '{"CleanSrcMetadataOnMismatch": 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 durch die Einstellung dieser Einstellung die Tabellensperre für Partitions-DDL-Änderungen während CDC true übersprungen. AWS DMS ignoriert partitioned-table-related DDL und setzt die Verarbeitung weiterer Änderungen im Binärprotokoll fort.

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 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 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)

DATUM

DATUM

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 ist -1,79E+308 bis -2,23E-308, 0 und 2,23E-308 bis 1,79E+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

WSTRING (Länge)

Länge bezieht sich hier auf die Länge des längsten Werts in ENUM.

SET

WSTRING (Länge)

Länge bezieht sich hier auf die Gesamtlänge aller Werte in 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.