Details
-
Task
-
Status: Stalled (View Workflow)
-
Minor
-
Resolution: Unresolved
-
None
Description
For example, UPDATE statement. It currently writes Update_rows_event and Write_row_event for every updated row. It should write only Update_rows_event, and the slave, when executing it, should create the historical row internally. Because existing binlogs already have Update_rows_event and Write_row_event, the slave should ignore all events that modify the history.
source include/have_binlog_format_row.inc;
|
source include/master-slave.inc;
|
|
|
create table t1 (a int, rs timestamp(6) not null, re timestamp(6) not null); |
|
|
sync_slave_with_master;
|
stop slave;
|
drop table t1; |
create table t1 (a int, rs timestamp(6) as row start, re timestamp(6) as row end, |
period for system_time(rs,re)) with system versioning; |
start slave;
|
|
|
connection master; |
# create two rows on the slave: one in the past, one with some fake row_start |
insert t1 values (1, '2010-10-10 10:10:10', '2011-11-11 11:11:11'); |
insert t1 values (2, '2012-12-12 12:12:12', from_unixtime(2147483647.999999)); |
|
|
sync_slave_with_master;
|
select * from t1; |
select * from t1 for system_time all; |
|
|
connection master; |
# now update the versioned row on the slave without leaving any trace |
update t1 set a=3, rs='2009-09-09 9:9:9' where a=2; |
sync_slave_with_master;
|
select * from t1; |
select * from t1 for system_time all; |
|
|
connection master; |
drop table t1; |
|
|
source include/rpl_end.inc;
|
Attachments
Issue Links
- is blocked by
-
MDEV-23486 RBR can bypass secure_timestamp=YES
-
- Stalled
-
Activity
The test case shows that currently with RBR one can create an arbitrary artificial history. One will be able to do it even if the versioning is refactored as in the summary, presuming that secure_timestamp is not YES.
That is, a much smaller fix to the reported issue would be to ignore values for row_start/row_end columns that come in row events, if secure_timestamp is YES. It's MDEV-23486
The rest of the suggested refactoring will reduce the binlog size, so it could be a useful optimization, but it's not necessary for the correctness anymore.
Hours can pass until slave will process the record, so the history timeline discrepancy may be unacceptable. Otherwise if we make history by the row event timestamp then it will not fix
MDEV-16370.Besides, points in the description script are good. But they are not related to
MDEV-16370. My point is: we have to fix this task like described, but we also have to pass microseconds in row event timestamp, so we may use it for history correctly and bypassMDEV-16370. The latter is done in scope ofMDEV-16370and does not depend on this task.