maria-developers team mailing list archive

[andrei.elkin@xxxxxxxxxx]

Aleksey, hello.

> 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?


Adding a new flag to Log_event could indeed force the binlog_version
increment. However as you're concerned with Rows_log_event the new field
could be added to this class and its header. You can find how to do that
in Rows_log_event::Rows_log_event.

Hope this is helpful.

Andrei



>
> 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
>
> _______________________________________________
> Mailing list: https://launchpad.net/~maria-developers
> Post to     : maria-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~maria-developers
> More help   : https://help.launchpad.net/ListHelp