Uploaded image for project: 'Debezium'
  1. Debezium
  2. DBZ-7594

Incorrect value of TIME(n) replicate from MySQL if the original value is negative

XMLWordPrintable

    • False
    • None
    • False
    • Critical

      Bug report

       

      We use Debezium as the replication tunnel for our MySQL CDC tool, and it works excellently. However, we found two unexpected behaviours on Debezium recently.

      • The first is, we got unexpeted value for data type TIME from the snapshot of the source database if the value is negative.

      For example, on MySQL, we have:

      mysql> show create table t\G
      *************************** 1. row ***************************
             Table: t
      Create Table: CREATE TABLE `t` (
        `id` bigint unsigned NOT NULL AUTO_INCREMENT,
        `t` time DEFAULT NULL,
        `t_6` time(6) DEFAULT NULL,
        PRIMARY KEY (`id`)
      ) ENGINE=InnoDB AUTO_INCREMENT=38 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci
      1 row in set (0.01 sec)
      
      
      mysql> select * from t;
      +----+-----------+------------------+
      | id | t         | t_6              |
      +----+-----------+------------------+
      | 37 | -00:20:38 | -00:20:38.000000 |
      +----+-----------+------------------+
      1 row in set (0.00 sec)

       

      But after we created the replication stream with `snapshot.mode` set to `initial`, and got the snapshot data sent by Debezium, we found that the data were converted to positive values. It seemed that the sign of the value was ignored.

       

      The second is: If we insert a negative value of TIME with the fractional part set to zero, we will get an unexpected value that with incorrect fractional part.

      For instance, we inserted a row like this on MySQL:

      mysql> insert into t (t, t_6) values ('-00:20:38.000000', '-00:20:38.000000');
      Query OK, 1 row affected (0.00 sec)
      
      
      mysql> select * from t;
      +----+-----------+------------------+
      | id | t         | t_6              |
      +----+-----------+------------------+
      | 37 | -00:20:38 | -00:20:38.000000 |
      | 38 | -00:20:38 | -00:20:38.000000 |
      +----+-----------+------------------+
      2 rows in set (0.00 sec)

       

      Then we got the wrong value like the picture shown below. Furthermore, this problem will not happen if the fractional part is not zero. e.g. if the value is '-00:20:38.000001', then the value sent be Debezium is 1238000001.

      What Debezium connector do you use and what version?

      2.5.2.Final

      What is the connector configuration?

      props.put("name", "abc");
      props.put("connector.class", "io.debezium.connector.mysql.MySqlConnector");
      props.put("database.hostname", "127.0.0.1");
      props.put("database.port", "53306");
      props.put("database.user", "root");
      props.put("database.password", "password");
      props.put("database.server.id", "100000");
      props.put("database.server.name", "abc");
      props.put("database.allowPublicKeyRetrieval", "true");

      What is the captured database version and mode of depoyment?

      On-prem, 8.0.30 MySQL Community Server

      What behaviour do you expect?

      • For the first problem. The data from the snapshot should take the sign of the value into account. i.e. the values should be negative, rather than positive.
      • For the second one. The fractional part of the negative TIME value should be zero if the one in original is zero. Not the '048576' one shown above.

      How to reproduce the issue using our tutorial deployment?

      You can follow the description above to reproduce this issue easily.

       

            Unassigned Unassigned
            vwagen Wu Xiang
            Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

              Created:
              Updated:
              Resolved: