Knowledge Center Monthly Newsletter - March 2025
Stay up to date with the latest from the Knowledge Center. See all new and updated Knowledge Center articles published in the last month and re:Post’s top contributors.
Wie migriere ich eine MySQL-Datenbank in einer UTC-fremden Zeitzone mithilfe von AWS DMS-Aufgaben?
Ich verfüge über eine MySQL-Quell- und -Ziel-Instance in einer UTC-fremden Zeitzone. Ich möchte die Datenbank mithilfe einer AWS-DMS-Aufgabe (AWS Database Migration Service) migrieren. Wie gehe ich dabei vor?
Kurzbeschreibung
Wenn Sie MySQL als Quelle verwenden, werden die Zeitstempeldaten nicht ordnungsgemäß migriert, falls Ihre MySQL-Quell-Instance eine UTC-fremde Zeitzone verwendet. Intern wird eine MySQL-Zeitstempelspalte als UTC gespeichert. Beim Auswählen eines Datums konvertiert MySQL die Zeitstempelspalte jedoch automatisch in die Zeitzone der aktuellen Sitzung. TIMESTAMP-Werte werden von MySQL aus der aktuellen Zeitzone in UTC konvertiert, um sie zu speichern. Beim Abrufen werden diese Werte von MySQL dann wieder von UTC in die aktuelle Zeitzone konvertiert.
Auch beim Speichern eines Datums in einem Zeitstempel konvertiert MySQL TIMESTAMP-Werte von Ihrer aktuellen Zeitzone in UTC. Beim Abrufen werden diese Werte dann wieder von UTC in die aktuelle Zeitzone konvertiert.
Bei Verwendung von AWS DMS sind Daten möglicherweise inkonsistent, wenn Ihre MySQL-Quell- und -Ziel-Instances nicht über eine UTC-Zeitzone verfügen. Wenn Sie beispielsweise eine MySQL-Quelldatenbank und eine MySQL-Zieldatenbank haben, die in der US-/Pazifikregion ausgeführt werden, handelt es sich nicht um eine UTC-Zeitzone. Die Daten in der Quelle werden also erfasst und dann als UTC auf das Ziel angewendet, was inkonsistente Daten zur Folge hat.
Lösung
Verwenden Sie zur Lösung dieses Problems ein zusätzliches Verbindungsattribut bzw. eine zusätzliche Endpunkteinstellung am Quellendpunkt: serverTimezone. Legen Sie dann den Wert auf die Zeitzone der MySQL-Datenbank fest.
serverTimezone=US/Pacific
Vergleichen Sie die folgenden Beispiele – eins mit einem zusätzlichen Verbindungsattribut am Quellendpunkt (serverTimezone) und eins ohne zusätzliches Verbindungsattribut.
Ohne zusätzliches Verbindungsattribut „serverTimezone“ am Quellendpunkt
Hinweis: Ohne zusätzliches Verbindungsattribut sind die Daten zwischen Ihren Quell- und Zieldatenbanken möglicherweise inkonsistent.
Quelle
mysql> SELECT @@global.time_zone, @@session.time_zone; +--------------------+---------------------+ | @@global.time_zone | @@session.time_zone | +--------------------+---------------------+ | US/Pacific | US/Pacific | +--------------------+---------------------+ mysql> create table test_tz ( id int primary key,t_date timestamp); Query OK, 0 rows affected (0.28 sec) mysql> insert into test_tz values (10, now()); Query OK, 1 row affected (0.31 sec) mysql> select * from test_tz; +----+---------------------+ | id | t_date | +----+---------------------+ | 10 | 2022-06-27 20:50:29 | +----+---------------------+ 1 row in set (0.25 sec)
Nachdem Sie nun eine AWS DMS-Aufgabe erstellt haben, sieht das Ziel nach der Migration der Daten und nach dem vollständigen Laden wie folgt aus:
Ziel
mysql> SELECT @@global.time_zone, @@session.time_zone; +--------------------+---------------------+ | @@global.time_zone | @@session.time_zone | +--------------------+---------------------+ | US/Pacific | US/Pacific | +--------------------+---------------------+ 1 row in set (0.30 sec) mysql> select * from test_tz; +----+---------------------+ | id | t_date | +----+---------------------+ | 10 | 2022-06-28 03:50:29 | ===> This shows timestamp in UTC in target +----+---------------------+ 1 row in set (0.25 sec)
Fügen Sie nun Daten in die Quelldatenbank ein.
Quelle
mysql> insert into test_tz values (11, now()); Query OK, 1 row affected (0.38 sec) mysql> select * from test_tz; +----+---------------------+ | id | t_date | +----+---------------------+ | 10 | 2022-06-27 20:50:29 | | 11 | 2022-06-27 21:10:13 | +----+---------------------+ 2 rows in set (0.24 sec)
Ziel
mysql> select * from test_tz; +----+---------------------+ | id | t_date | +----+---------------------+ | 10 | 2022-06-28 03:50:29 | | 11 | 2022-06-28 04:10:13 | ===> This shows timestamp in UTC in target +----+---------------------+ 2 rows in set (0.25 sec)
Mit zusätzlichem Verbindungsattribut „serverTimezone=US/Pacific“ am Quellendpunkt
Daten nach vollständigem Laden:
Quelle
mysql> select * from test_tz; +----+---------------------+ | id | t_date | +----+---------------------+ | 10 | 2022-06-27 20:50:29 | | 11 | 2022-06-27 21:10:13 | +----+---------------------+
Ziel
mysql> select * from test_tz; +----+---------------------+ | id | t_date | +----+---------------------+ | 10 | 2022-06-27 20:50:29 | | 11 | 2022-06-27 21:10:13 | +----+---------------------+
Daten während der Erfassung geänderter Daten
Quelle
3 rows in set (0.25 sec) +----+---------------------+ | 12 | 2022-06-28 04:12:06 | | 11 | 2022-06-28 04:10:13 | | 10 | 2022-06-28 03:50:29 | +----+---------------------+ | id | t_date | +----+---------------------+ mysql> select * from test_tz; mysql> mysql> Query OK, 1 row affected (0.38 sec) mysql> insert into test_tz values (12, current_time());
Ziel
3 rows in set (0.25 sec) +----+---------------------+ | 12 | 2022-06-28 04:12:06 | | 11 | 2022-06-28 04:10:13 | | 10 | 2022-06-28 03:50:29 | +----+---------------------+ | id | t_date | +----+---------------------+ mysql> select * from test_tz;
Das zusätzliche Verbindungsattribut „serverTimezone“ ist also bei der Migration und Replikation von Zeitstempeldaten hilfreich, wenn Ihre MySQL-Quell-Instance eine UTC-fremde Zeitzone verwendet.

Relevanter Inhalt
- AWS OFFICIALAktualisiert vor 3 Jahren
- AWS OFFICIALAktualisiert vor 2 Jahren
- AWS OFFICIALAktualisiert vor 3 Jahren
- AWS OFFICIALAktualisiert vor 3 Jahren