[MDEV-18432] RBR logging of system versioned tables Created: 2019-01-31  Updated: 2023-12-22

Status: Stalled
Project: MariaDB Server
Component/s: Replication, Versioned Tables
Fix Version/s: 11.5

Type: Task Priority: Minor
Reporter: Sergei Golubchik Assignee: Aleksey Midenkov
Resolution: Unresolved Votes: 1
Labels: RBR

Issue Links:
Blocks
is blocked by MDEV-23486 RBR can bypass secure_timestamp=YES Stalled
Sub-Tasks:
Key
Summary
Type
Status
Assignee
MDEV-18727 System Versioning: optimize DML opera... Technical task Closed Aleksey Midenkov  

 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;



 Comments   
Comment by Aleksey Midenkov [ 2020-01-08 ]

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 bypass MDEV-16370. The latter is done in scope of MDEV-16370 and does not depend on this task.

Comment by Sergei Golubchik [ 2020-08-14 ]

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.

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