Details
-
Bug
-
Status: Closed (View Workflow)
-
Critical
-
Resolution: Fixed
-
11.5.1
-
None
Description
If a binary log event is written when timestamp is 4294967295 (exactly that, not just any value greater than 2147483647), mysqlbinlog ignores it, and apparently the rest of the binary log.
It is not about displaying in verbose mode – it ignores events completely, so that they are not replayed upon trying to restore data from the binlog.
--source include/have_log_bin.inc
|
|
|
--let $datadir= `select @@datadir`
|
|
|
reset master;
|
create table t (a int); |
insert into t values (1); |
set @@timestamp= 4294967295; |
insert into t values (2); |
select * from t; |
|
|
flush binary logs; |
drop table t; |
|
|
show binlog events in 'master-bin.000001'; |
--exec $MYSQL_BINLOG $datadir/master-bin.000001
|
--exec $MYSQL_BINLOG $datadir/master-bin.000001 | $MYSQL test
|
select * from t; |
|
|
# Cleanup
|
drop table t; |
In the test case above, row (1) is inserted with a normal timestamp, row (2) – with 4294967295.
In mysqlbinlog output we only see the first event:
|
bb-11.4-timestamp 6a706d142be3309de89c28bcb48e91a72e8e8f69 |
#240114 1:01:14 server id 1 end_log_pos 0 CRC32 0xf50d8a49 Query thread_id=5 exec_time=0 error_code=0 xid=0
|
SET TIMESTAMP=1705186874/*!*/;
|
insert into t values (1)
|
/*!*/;
|
# at 602
|
#240114 1:01:14 server id 1 end_log_pos 675 CRC32 0xdcf61fdb Query thread_id=5 exec_time=0 error_code=0 xid=0
|
SET TIMESTAMP=1705186874/*!*/;
|
COMMIT
|
/*!*/;
|
DELIMITER ;
|
# End of log file
|
and upon replaying only one row is inserted:
select * from t;
|
a
|
1
|
drop table t;
|
Meanwhile, the record is actually in the binary log and can be seen in show binlog events output:
master-bin.000001 469 Gtid 1 511 BEGIN GTID 0-1-2
|
master-bin.000001 511 Query 1 0 use `test`; insert into t values (1)
|
master-bin.000001 602 Query 1 675 COMMIT
|
master-bin.000001 675 Gtid 1 717 BEGIN GTID 0-1-3
|
master-bin.000001 717 Query 1 0 use `test`; insert into t values (2)
|
master-bin.000001 808 Query 1 881 COMMIT
|
Attachments
Issue Links
- is caused by
-
MDEV-32188 make TIMESTAMP use whole 32-bit unsigned range
-
- Closed
-
Activity
is (now?)
Yes, as of MDEV-32188. That's also the (only) reason why it was filed as "major" – because it was a part of the new feature testing, otherwise of course it is as a corner case as it gets.
The value 0xffffffff (aka 4294967295) was used as a magic placeholder to mean "no --stop-datetime given", which fails as described since 0xffffffff is (now?) a valid timestamp value.
Patch: https://lists.mariadb.org/hyperkitty/list/commits@lists.mariadb.org/thread/A243GUODBIXAZCO3C6UHM4AP6PPBCXWD/