[MDEV-5377] Row-based replication of MariaDB temporal data types with FSP>0 into a different column type Created: 2013-12-03  Updated: 2019-06-28  Resolved: 2018-12-04

Status: Closed
Project: MariaDB Server
Component/s: Replication
Affects Version/s: 5.3.12, 5.5.37, 10.0.10
Fix Version/s: 10.1.2

Type: Bug Priority: Major
Reporter: Alexander Barkov Assignee: Alexander Barkov
Resolution: Duplicate Votes: 3
Labels: None

Issue Links:
Blocks
is blocked by MDEV-5528 Command line variable to choose Maria... Closed
Duplicate
duplicates MDEV-5528 Command line variable to choose Maria... Closed
duplicates MDEV-10746 Replicate Data from 10.0 -> 10.1 (Cor... Closed
duplicates MDEV-12744 Corrupted replication event was detec... Closed
PartOf
includes MDEV-6389 DATETIME w/ transportable tablespaces... Open
Relates
relates to MDEV-19906 Show internal type for TIMESTAMP, DAT... Closed
relates to MDEV-9567 mysqlbinlog fails to read binlog even... Closed

 Description   

Row based replication of the TIME(N), DATETIME(N) and TIMESTAMP(N)
data types does not store column metadata into the binary log, so
slave does not have any information about the precision of the column on
master. Slave can only assume that the precision is exactly the same
on master and on slave.

This puts some limitations. Examples when RBR does not work:

  • From TIME(N) to TIME(M), for N!=M
  • From TIME(N) to another data type, e.g. VARCHAR or DECIMAL.
  • From TIME(N) in a MariaDB master to TIME(N) in a MySQL56 slave.

 Comments   
Comment by Sergei Golubchik [ 2014-01-14 ]

one possible solution — use MySQL-5.6 compatible on-disk format for temporal columns by default.

Comment by Alexander Barkov [ 2014-01-14 ]

See also:
MDEV-5528 Command line variable to choose MariaDB-5.3 vs MySQL-5.6 temporal data formats

Comment by Elena Stepanova [ 2014-04-23 ]

Just for a note,

  • From TIME(N) to another data type, e.g. VARCHAR or DECIMAL.

This one doesn't seem to work on 5.6 either.

Comment by Sergei Golubchik [ 2014-06-24 ]

It seems to be that the only reasonable solution is to use MySQL-5.6 temporal format and typecodes (that we already support anyway for compatibility reasons). Unfortunately, this cannot be done in 10.0...

Comment by Alexander Barkov [ 2018-12-04 ]

This problem was fixed by MDEV-5528.

Generated at Thu Feb 08 07:03:48 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.