如何在 Amazon DMS 中处理 MySQL/MariaDB TIME 列

Question

我们在使用 Amazon DMS 持续复制 MySQL/MariaDB 数据库时遇到问题。

该问题特别发生在

TIME

列上，其值会出现如下乱码：

• 13:22:31

  变成

  112:16:02

• 13:23:59

  变为

  -911:43:62

  （实际上低于 -838:59:59.999999 的

  记录的最小值）

迄今为止我们看到的最大值是：

• -1023:63:63

  （来自

  13:11:36

  ）

• 1023:60:01

  （来自

  13:07:51

  ）

但奇怪的是，

-1023:32:00

来自

00:20:48

。好像根本就没有什么规律...😞

它与

all TIME

 列一致发生，因此不是由于其他问题造成的。我的猜测是，这与 DMS 无法正确读取 binlog 中 

TIME

 列的格式有关。

是否有

任何方法可以将这些有缺陷的值转换回应有的值？我们可以完全控制这些值，并且可以运行代码来执行转换（Python 或 JS 最好，但我们可以采取任何方式）。但考虑到上述时间如此接近并导致如此截然不同的表述，我的希望非常低......

这个问题似乎相关，但仍然没有解决方案或解决方法。在他们的例子中，当值为负时，值似乎被截断为 00:00:00

，当它们太大时，则被截断为 

23:59:59

。

规格：

MariaDB 版本
• 10.1.46
InnoDB版本
• 5.6.49-89.0
• mysql56_temporal_format

   是 

  ON

  （

  参见文档）
我们使用的是 AWS DMS Serverless，因此我们无法控制版本
DMS 目标是 Kinesis Data Streams（JSON 格式）

Answer 1

好吧，我刚刚走进了死胡同......😞

唯一可能的解决方案是 Amazon DMS 修复此错误。

---

我尝试通过复制所有 86,400 个可能值（60 秒 * 60 分钟 * 24 小时）来创建查找表，起初它似乎有效......但不幸的是，映射中存在大量重复项（由于由于接收到的数据缺乏精度），

这意味着即使是编程解决方案也会达到完全相同的结果（因为相同的输入=相同的输出）。

以下是重复项的示例：

例如，当我们收到

-841:19:63

时，无法判断正确的值是

09:29:39

还是

09:30:03

。但至少价值观有些接近......

---

这是我用来在 MariaDB 中生成表的代码：

CREATE TABLE my_table AS
SELECT
  CONCAT(LPAD(hours.seq, 2, '0'), ':', LPAD(minutes.seq, 2, '0'), ':', LPAD(seconds.seq, 2, '0')) AS t1,
  CAST('00:00:00' AS TIME) AS t2
SELECT *
FROM (
  SELECT seq
  FROM seq_0_to_59
) AS seconds,
(
  SELECT seq
  FROM seq_0_to_59
) AS minutes,
(
  SELECT seq
  FROM seq_0_to_23
) AS hours;
--
UPDATE my_table
SET t2 = CAST(t1 AS TIME);