Wie migriere ich eine MySQL-Datenbank in einer UTC-fremden Zeitzone mithilfe von AWS DMS-Aufgaben?

Lesedauer: 4 Minute
0

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.


AWS OFFICIAL
AWS OFFICIALAktualisiert vor 2 Jahren