maria-developers team mailing list archive

[Aleksey Midenkov <midenok@xxxxxxxxx>]

Hi, Sergei,

Thank you for observations! This task is in progress. While doing it I
found out that RBR doesn't replicate timestamp fractions. That is: it gets
seconds from event timestamp marker and adds fractions from system time.
This causes bugs in System Versioning. More on it in Bug 6 here:
https://github.com/tempesta-tech/mariadb/issues/578#issuecomment-470533050

I propose to fix it by adding timestamp fractions field to Log_event header
after FLAGS_OFFSET. To support backwards compatibility it is needed to
increment fdle->binlog_version and probably add new flag
LOG_EVENT_HAS_SEC_PART_F (for support sending Log_event without fractions).
Do you agree?

On Thu, Jan 31, 2019 at 1:10 PM Sergei Golubchik <serg@xxxxxxxxxxx> wrote:

> Hi, Aleksey!
>
> On Jan 31, Aleksey Midenkov wrote:
> > revision-id: 14c2f90ad08 (versioning-1.0.7-1-g14c2f90ad08)
> > parent(s): a8efe7ab1f2
> > author: Aleksey Midenkov <midenok@xxxxxxxxx>
> > committer: Aleksey Midenkov <midenok@xxxxxxxxx>
> > timestamp: 2018-11-17 16:30:10 +0300
> > message:
> >
> > Idempotent INSERT events for system versioning
> >
> > Case 1: Rows_log_event::write_row() always overwrite historical row.
> >
> > Related to MDEV-16370.
>
> I realized that the whole RBR logging of system versioned tables is
> wrong.
>
> For an update you log update_row event and write_row event separately
> and execute them separately. It allows trivially to manipulate the history.
> See a test case attached.
>
> To fix this, the slave should ignore all events that modify the history.
> And generate them locally. Say, an update on the master generates
> update_row and write_row events. The slave executes update_row event
> which updates a current row and this also should generate the historical
> row. Then the slave ignores write_row event.
>
> Of course, as an optimization, the master should not generate historical
> write_row events, but as my test case shows, they can be forged, so the
> slave should ignore them anyway, if they happen to come.
>
> I've created a new https://jira.mariadb.org/browse/MDEV-18432 for that,
> let's not have it tied to MDEV-16370.
>
> Regards,
> Sergei
> Chief Architect MariaDB
> and security@xxxxxxxxxxx
>


-- 
All the best,

Aleksey Midenkov
@midenok