¿Cómo puedo migrar una base de datos MySQL en una zona horaria no UTC mediante tareas de AWS DMS?

Descripción corta

Cuando usa MySQL como origen, los datos de la marca de tiempo no se migran correctamente si la instancia MySQL de origen usa una zona horaria que no sea UTC. Internamente, una columna de marca de tiempo de MySQL se almacena como UTC. Sin embargo, cuando selecciona una fecha, MySQL convierte automáticamente la columna de marca de tiempo a la zona horaria de la sesión actual. MySQL convierte los valores de TIMESTAMP de la zona horaria actual a UTC para su almacenamiento. A continuación, MySQL vuelve a convertir esos valores UTC a la zona horaria actual para su recuperación.

Del mismo modo, cuando almacena una fecha en una marca de tiempo, MySQL convierte los valores de TIMESTAMP de su zona horaria actual a UTC. A continuación, vuelve a convertir esos valores UTC a la zona horaria actual para su recuperación.

Cuando usa AWS DMS, los datos pueden ser incoherentes si las instancias MySQL de origen y destino tienen una zona horaria distinta de UTC. Por ejemplo, si tiene una base de datos MySQL de origen y de destino que se ejecuta en EE. UU./Pacífico, no está en UTC. Por lo tanto, los datos del origen se capturan y luego se aplican al destino como UTC, lo que hace que los datos sean inconsistentes.

Resolución

Para resolver este problema, utilice una configuración de atributo de conexión o punto de conexión adicional para el valor serverTimezone del punto de conexión de origen. A continuación, defina el valor en la zona horaria de la base de datos MySQL.

serverTimezone=US/Pacific

Compare estos ejemplos, uno con un atributo de conexión adicional (extra connection attribute, ECA) en el valor serverTimezone del punto de conexión de origen, y otro sin ECA.

Sin ECA en el valor serverTimezone del punto de conexión de origen

Nota: Si no usa el ECA, es posible que observe inconsistencia de datos entre las bases de datos de origen y de destino.

Origen

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)

Ahora que ha creado una tarea de AWS DMS, después de migrar los datos, tendrá este aspecto después de la carga completa:

Destino

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)

Ahora, realice una inserción en la base de datos de origen.

Origen

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)

Destino

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)

Con ECA en el valor serverTimezone=US/Pacific (EE. UU./Pacífico) del punto de conexión de origen

Datos después de la carga completa:

Origen

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

Destino

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

Datos durante la captura de datos de cambios (CDC)

Origen

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

Destino

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;

Por lo tanto, un ECA en el valor serverTimezone le ayuda a migrar y replicar los datos de la marca de tiempo cuando la instancia MySQL de origen utiliza una zona horaria que no es UTC.

---