Re: [Maria-developers] ab6ef429a84: MDEV-16370 row-based binlog events (updates by primary key) can not be applied multiple times to system versioned tables
Hi, Aleksey! On Jan 31, Aleksey Midenkov wrote:
revision-id: ab6ef429a84 (versioning-1.0.7-2-gab6ef429a84) parent(s): 14c2f90ad08 author: Aleksey Midenkov <midenok@gmail.com> committer: Aleksey Midenkov <midenok@gmail.com> timestamp: 2018-11-26 12:46:37 +0300 message:
MDEV-16370 row-based binlog events (updates by primary key) can not be applied multiple times to system versioned tables
Case 2:
* Idempotent BINLOG updates: duplicate key on history row is skipped; * Fix row start and warn when applying BINLOG from the past.
As far as I can see now you cannot just arbitrarily adjust row_start. Think of it in term or application time period tables, a primary key is (kind of) defined WITHOUT OVERLAPS. There is no explicit constraint, it happens automatically when the history is valid. Now, here's your test case: timestamp=100; insert (1,1) -> the table has (1,1,100,MAX); timestamp=300; update to (1,3) -> (1,1,100,300),(1,3,300,MAX); timestamp=200; update to (1,2) -> here the hisory row should've been (1,3,300,200) but you adjust it to get 1,1,100,300 1,3,199,200 1,2,200,MAX and if you select AS OF 199, you'll get two rows for the pk=1 So, let's * ignore HA_ERR_FOUND_DUPP_KEY (please check if it's needed for insert or delete too) * add TIMESTAMP=xxx to mysqldumps. can vers_insert_history_row see row_start>row_end in a normal use case? no replication or any other way of adjusting the timestamp. equality can surely happen, but greater than ? Regards, Sergei Chief Architect MariaDB and security@mariadb.org
Hi Sergei! On Wed, Mar 13, 2019 at 7:16 PM Sergei Golubchik <serg@mariadb.org> wrote:
Hi, Aleksey!
On Jan 31, Aleksey Midenkov wrote:
revision-id: ab6ef429a84 (versioning-1.0.7-2-gab6ef429a84) parent(s): 14c2f90ad08 author: Aleksey Midenkov <midenok@gmail.com> committer: Aleksey Midenkov <midenok@gmail.com> timestamp: 2018-11-26 12:46:37 +0300 message:
MDEV-16370 row-based binlog events (updates by primary key) can not be applied multiple times to system versioned tables
Case 2:
* Idempotent BINLOG updates: duplicate key on history row is skipped; * Fix row start and warn when applying BINLOG from the past.
As far as I can see now you cannot just arbitrarily adjust row_start.
Think of it in term or application time period tables, a primary key is (kind of) defined WITHOUT OVERLAPS. There is no explicit constraint, it happens automatically when the history is valid.
Now, here's your test case:
timestamp=100; insert (1,1) -> the table has (1,1,100,MAX); timestamp=300; update to (1,3) -> (1,1,100,300),(1,3,300,MAX); timestamp=200; update to (1,2) -> here the hisory row should've been (1,3,300,200) but you adjust it to get
1,1,100,300 1,3,199,200 1,2,200,MAX
and if you select AS OF 199, you'll get two rows for the pk=1
So, let's
* ignore HA_ERR_FOUND_DUPP_KEY (please check if it's needed for insert or delete too) * add TIMESTAMP=xxx to mysqldumps.
Add SET TIMESTAMP for each versioned record or just single SET TIMESTAMP per dump? I almost made the former when I realized that you could mean the latter.
can vers_insert_history_row see row_start>row_end in a normal use case? no replication or any other way of adjusting the timestamp. equality can surely happen, but greater than ?
I don't know of such cases.
Regards, Sergei Chief Architect MariaDB and security@mariadb.org
-- All the best, Aleksey Midenkov @midenok
participants (2)
-
Aleksey Midenkov -
Sergei Golubchik