Details
-
Bug
-
Status: Closed (View Workflow)
-
Critical
-
Resolution: Fixed
-
10.0.21, 10.1(EOL), 10.2(EOL)
Description
Inserting a fractional second into MySQL 5.6 and MariaDB yields different results, and as a consequence, replicating from a MySQL 5.6 master into a MariaDB 10 slave creates an inconsistent slave.
On Oracle/Percona MySQL 5.6 the value is rounded:
|
master>create table test_datetime (dt datetime not null);
|
Query OK, 0 rows affected (0.06 sec)
|
|
master>insert into test_datetime values ('2015-10-05 10:00:00.501');
|
Query OK, 1 row affected (0.12 sec)
|
|
master>select * from test_datetime;
|
+---------------------+
|
| dt |
|
+---------------------+
|
| 2015-10-05 10:00:01 |
|
+---------------------+
|
1 row in set (0.00 sec)
|
On MariaDB 10 it is not:
MariaDB slave [rick]> insert into test_datetime values ('2015-10-05 10:00:00.501');
|
Query OK, 1 row affected (0.00 sec)
|
|
MariaDB slave [rick]> select * from test_datetime;
|
+---------------------+
|
| dt |
|
+---------------------+
|
| 2015-10-05 10:00:00 |
|
+---------------------+
|
2 rows in set (0.00 sec)
|
Inconsistent MariaDB slave test:
master>insert into test_datetime values ('2015-10-05 10:00:00.501');
|
Query OK, 1 row affected (0.00 sec)
|
master>select * from test_datetime;
|
+---------------------+
|
| dt |
|
+---------------------+
|
| 2015-10-05 10:00:01 |
|
+---------------------+
|
1 row in set (0.00 sec)
|
|
MariaDB slave [rick]> select * from test_datetime;
|
+---------------------+
|
| dt |
|
+---------------------+
|
| 2015-10-05 10:00:00 |
|
+---------------------+
|
1 row in set (0.00 sec)
|
This issue affects both datetime and timestamp column types.
MariaDB should have same behaviour regarding fractional seconds as Oracle and Percona, or interoperability is compromised. For example, a pt-table-checksum always fails due to these rounding differences when comparing a MariaDB slave against a non MariaDB master.
Until this bug is fixed we will be unable to use multi source replication, which was the primary reason for us to use MariaDB.
Attachments
Issue Links
- is blocked by
-
MDEV-13995 MAX(timestamp) returns a wrong result near DST change
-
- Closed
-
-
MDEV-15176 Storing DATETIME-alike VARCHAR data into TIME produces wrong results
-
- Closed
-
-
MDEV-15205 Remove mysql_type_to_time_type()
-
- Closed
-
-
MDEV-15262 Wrong results for SELECT..WHERE non_indexed_datetime_column=indexed_time_column
-
- Closed
-
-
MDEV-15287 Bad result for LEAST/GREATEST(datetime_alike_string, time)
-
- Closed
-
-
MDEV-15289 Binding an out-of-range DATETIME value in binary protocol breaks replication
-
- Closed
-
-
MDEV-15293 CAST(AS TIME) returns bad results for LAST_VALUE(),NAME_CONST(),SP variable
-
- Closed
-
-
MDEV-15340 Wrong result HOUR(case_expression_with_time_and_datetime)
-
- Closed
-
-
MDEV-15363 Wrong result for CAST(LAST_DAY(TIME'00:00:00') AS TIME)
-
- Closed
-
-
MDEV-15406 NO_ZERO_IN_DATE erroneously affects how CAST(AS DATE) warns about fractional digit truncation
-
- Closed
-
-
MDEV-16910 Add class VDec
-
- Closed
-
-
MDEV-16928 Move MYSQL_TIME initialization from Field_xxx::store_time_dec() to new constructors Time() and Datetime()
-
- Closed
-
-
MDEV-16935 Change the parameter of Field_xxx::store_TIME_with_dec() to const Datetime* and const Time*
-
- Closed
-
-
MDEV-16938 Move Item::get_time_with_conversion() to Time
-
- Closed
-
-
MDEV-16939 Move TIMESTAMP truncation code to Field_timestamp::store_TIME_with_warn
-
- Closed
-
-
MDEV-16991 Rounding vs truncation for TIME, DATETIME, TIMESTAMP
-
- Closed
-
- relates to
-
MDEV-15225 Can't import .ibd file with temporal type format differing from mysql56_temporal_format
-
- Closed
-
-
MDEV-17216 Assertion `!dt->fraction_remainder(decimals())' failed in Field_temporal_with_date::store_TIME_with_warning
-
- Closed
-
- links to
Btw, Oracle Database also rounds (not truncates) temporal data:
2001-01-01 10:20:30.457000
So does PostgreSQL.
So it might be useful to add an option to choose between truncation and rounding for temporal data in MariaDB.
This option can be enforced to rounding when processing a binary log from MySQL.