Comment migrer une base de données MySQL dans un fuseau horaire autre que UTC à l'aide des tâches AWS DMS ?

Dernière mise à jour : 28/07/2022

J'ai une instance MySQL source et cible qui se trouve dans un fuseau horaire autre que UTC. Je souhaite migrer la base de données à l'aide d'une tâche AWS Database Migration Service (AWS DMS). Comment procéder ?

Courte description

Lorsque vous utilisez MySQL comme source, les données d'horodatage ne sont pas migrées correctement si votre instance MySQL source utilise un fuseau horaire autre que UTC. En interne, une colonne d'horodatage MySQL est stockée au format UTC. Mais, lorsque vous sélectionnez une date, MySQL convertit automatiquement la colonne d'horodatage dans le fuseau horaire de la session en cours. MySQL convertit les valeurs TIMESTAMP du fuseau horaire actuel en UTC pour le stockage. Ensuite, MySQL convertit ces valeurs d’UTC vers le fuseau horaire actuel pour les récupérer.

De même, lorsque vous stockez une date dans un horodatage, MySQL convertit les valeurs TIMESTAMP de votre fuseau horaire actuel en UTC. Ensuite, il convertit ces valeurs d’UTC vers le fuseau horaire actuel pour les récupérer.

Lorsque vous utilisez AWS DMS, les données peuvent être incohérentes si vos instances MySQL source et cible ont un fuseau horaire autre que l'UTC. Par exemple, si vous avez une base de données MySQL source et cible qui s'exécute dans le fuseau horaire du Pacifique, elle n'est pas en UTC. Ainsi, les données de la source sont capturées puis appliquées à la cible en UTC, ce qui rend les données incohérentes.

Solution

Pour résoudre ce problème, utilisez un paramètre d'attribut de connexion/point de terminaison supplémentaire dans le point de terminaison source serverTimezone. Ensuite, définissez la valeur sur le fuseau horaire de la base de données MySQL.

serverTimezone=US/Pacific

Comparez ces exemples, l'un avec un attribut de connexion supplémentaire (ECA) dans le point de terminaison source serverTimezone, et l'autre sans ECA.

Sans attribut ECA serverTimezone dans le point de terminaison source

Remarque : si vous n'utilisez pas ECA, vous constaterez peut-être une incohérence des données entre vos bases de données source et cible.

Source

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)

Maintenant que vous avez créé une tâche AWS DMS, après la migration des données, elle ressemble à ceci après le chargement complet :

Cible

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)

Effectuez maintenant une insertion dans la base de données source.

Source

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)

Cible

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)

Avec ECA serverTimezone=US/Pacific dans le point de terminaison source

Données après chargement complet :

Source

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

Cible

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

Données lors de la saisie des données de modification (CDC)

Source

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

Cible

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;

Ainsi, l’attribut ECA serverTimezone vous aide à migrer et à répliquer les données d'horodatage lorsque votre instance MySQL source utilise un fuseau horaire autre qu’UTC.


Cet article vous a-t-il été utile ?


Avez-vous besoin d'aide pour une question technique ou de facturation ?