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
Activity
Field | Original Value | New Value |
---|---|---|
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: {code} 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) {code} On MariaDB 10 it is not: {code} 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) {code} Inconsistent MariaDB slave test: {code} 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) {code} 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. |
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: {code} 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) {code} On MariaDB 10 it is not: {code} 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) {code} Inconsistent MariaDB slave test: {code} 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) {code} 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. |
Assignee | Alexander Barkov [ bar ] |
Summary | Inserting fractional seconds into MyQL 5.6 master breaks consistency on MariaDB 10 slave | Inserting fractional seconds into MySQL 5.6 master breaks consistency on MariaDB 10 slave |
Fix Version/s | 10.0 [ 16000 ] |
Sprint | 10.0.34 [ 224 ] |
Affects Version/s | 10.2 [ 14601 ] | |
Affects Version/s | 10.1 [ 16100 ] |
Fix Version/s | 10.2 [ 14601 ] | |
Fix Version/s | 10.3 [ 22126 ] | |
Fix Version/s | 10.1 [ 16100 ] |
Sprint | 10.0.34 [ 224 ] | 10.0.34, 10.1.31 [ 224, 225 ] |
Sprint | 10.0.34, 10.1.31 [ 224, 225 ] | 10.0.34, 10.1.31, 10.2.13 [ 224, 225, 228 ] |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Status | Open [ 1 ] | In Progress [ 3 ] |
Sprint | 10.0.34, 10.1.31, 10.2.13 [ 224, 225, 228 ] | 10.0.34, 10.1.31, 10.2.13, 10.3.5-1 [ 224, 225, 228, 229 ] |
Link |
This issue relates to |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue blocks |
Link |
This issue blocks |
Link |
This issue is blocked by |
Link | This issue is blocked by MDEV-15310 [ MDEV-15310 ] |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Sprint | 10.0.34, 10.1.31, 10.2.13, 10.3.5-1 [ 224, 225, 228, 229 ] |
Fix Version/s | 10.0 [ 16000 ] | |
Fix Version/s | 10.1 [ 16100 ] |
Comment |
[ Oracle:
{code:sql} ALTER SESSION SET NLS_TIMESTAMP_FORMAT = 'YYYY-MM-DD HH:MI:SS.FF'; DROP TABLE t1; CREATE TABLE t1 (a TIMESTAMP(3)); INSERT INTO t1 VALUES (TIMESTAMP'2001-01-01 23:59:59.999789'); SELECT * FROM t1; {code} {noformat} 2001-01-02 12:00:00.000000 {noformat} What? ] |
Fix Version/s | 10.4 [ 22408 ] | |
Fix Version/s | 10.2 [ 14601 ] | |
Fix Version/s | 10.3 [ 22126 ] |
Status | In Progress [ 3 ] | Stalled [ 10000 ] |
Link |
This issue is blocked by |
Status | Stalled [ 10000 ] | In Progress [ 3 ] |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Labels | Compatibility |
Link |
This issue is blocked by |
Link |
This issue is blocked by |
Remote Link | This issue links to "MySQL Bug#78802 (Web Link)" [ 28513 ] |
Remote Link | This issue links to "MySQL Bug#68760 (Web Link)" [ 28514 ] |
Remote Link | This issue links to "MySQL Bug#76948 (Web Link)" [ 28515 ] |
Link |
This issue relates to |
Status | In Progress [ 3 ] | Stalled [ 10000 ] |
Assignee | Alexander Barkov [ bar ] | Andrei Elkin [ elkin ] |
Status | Stalled [ 10000 ] | In Review [ 10002 ] |
Assignee | Andrei Elkin [ elkin ] | Alexander Barkov [ bar ] |
Status | In Review [ 10002 ] | Stalled [ 10000 ] |
Fix Version/s | 10.4.1 [ 23228 ] | |
Fix Version/s | 10.4 [ 22408 ] | |
Resolution | Fixed [ 1 ] | |
Status | Stalled [ 10000 ] | Closed [ 6 ] |
Link | This issue is blocked by MDEV-15310 [ MDEV-15310 ] |
Workflow | MariaDB v3 [ 71871 ] | MariaDB v4 [ 149685 ] |