如何使用 AWS DMS 任務來遷移非 UTC 時區的 MySQL 資料庫？

簡短描述

當您使用 MySQL 作為來源時，如果來源 MySQL 執行個體使用非 UTC 時區，則時間戳記資料不會正確遷移。在內部，MySQL 時間戳記欄儲存為 UTC。但是，當您選擇日期時，MySQL 會自動將時間戳記欄轉換為目前工作階段的時區。MySQL 將時間戳記值從目前時區轉換為 UTC 進行儲存。然後，MySQL 將這些值從 UTC 轉換回目前時區以進行擷取。

同樣，當您將日期保存於時間戳記時，MySQL 會把時間戳記值從目前時區轉換為 UTC。然後，它會把這些值從 UTC 轉換回目前時區以進行擷取。

使用 AWS DMS 時，如果來源及目標 MySQL 執行個體的時區不是 UTC，資料可能會不一致。例如，如果您有在美國/太平洋地區執行的來源及目標 MySQL 資料庫，則該資料庫不是 UTC。因此，擷取來源資料後，會以 UTC 的形式套用至目標，這會導致資料不一致。

解決方案

若要解決此問題，請在來源端點 serverTimezone 使用額外的連線屬性/端點設定。然後，將該值設定為 MySQL 資料庫的時區。

serverTimezone=US/Pacific

比較這些範例，其中一個範例具有來源端點 serverTimezone 的額外連線屬性 (ECA)，而另一個不具 ECA。

來源端點無 ECA serverTimezone

附註：如果您未使用 ECA，您可能會看到來源資料庫與目標資料庫之間的資料不一致。

來源

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)

現在您已建立了 AWS DMS 任務，在資料遷移並完全載入之後，看起來會像這樣：

目標

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)

現在，在來源資料庫執行插入。

來源

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)

目標

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)

在來源端點使用 ECA serverTimezone = 美國/太平洋

完全載入後的資料：

來源

mysql> select * from test_tz;
   +----+---------------------+
   | id | t_date              |
   +----+---------------------+
   | 10 | 2022-06-27 20:50:29 |
   | 11 | 2022-06-27 21:10:13 |
   +----+---------------------+

目標

mysql> select * from test_tz;
   +----+---------------------+
   | id | t_date              |
   +----+---------------------+
   | 10 | 2022-06-27 20:50:29 |
   | 11 | 2022-06-27 21:10:13 |
   +----+---------------------+

異動資料擷取期間的資料 (CDC)

來源

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

目標

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 執行個體使用非 UTC 時區時，ECA serverTimezone 可協助您遷移並複寫時間戳記資料。

---