[MDEV-15922] system versioning with trx_id breaks when replicated Created: 2018-04-18  Updated: 2023-10-06

Status: Stalled
Project: MariaDB Server
Component/s: Replication, Versioned Tables
Affects Version/s: 10.3
Fix Version/s: 10.4

Type: Bug Priority: Minor
Reporter: Sergei Golubchik Assignee: Aleksey Midenkov
Resolution: Unresolved Votes: 0
Labels: trx-versioning

Issue Links:
Relates
relates to MDEV-16226 TRX_ID-based System Versioning refact... Stalled
relates to MDEV-16211 Contents of transaction_registry shou... Closed

 Description   

if system versioning is done via innodb internal transaction identifiers, there is no way to replicate such table to have identical data on the slave.

In SBR replication will work and replicated tables will be usable, but they'll have different transaction identifiers. in RBR it won't work at all. And one could not bootstrap the slave by copying tables over.

All this, supposedly, can be fixed by using gtrid instead of innodb internal transaction ids. That is, by adding gtrid columns to the transaction registry table and storing gtrids in versioned tables.



 Comments   
Comment by Aleksey Midenkov [ 2018-05-23 ]

Postponed.

elenst [00:37]
events on tables versioned with transaction id are always replicated as statement, why is it? Is it supposed to solve https://jira.mariadb.org/browse/MDEV-15922 ? If so, why is it still open, if not, why was it done?
 
@midenok ^ would you know anything about it?
midenok [17:13]
@elenst Yes, TRX_ID is impossible to replicate as is, so RBR was silently converted to SBR. MDEV-15922 suggests to use GTID instead. Which is shared between hosts, so it could be possible to use RBR.
marko [17:17]
@midenok maybe in 10.4 the transaction_registry could help map short transaction ID to GTID, and then replication could use GTID even though the engine writes short trx id to the table.
writing GTID would bloat the table too much, I am afraid
midenok [17:20]
Marko, good point. @serg Do we need MDEV-15922 in 10.3?
serg [17:21]
ah, right. I mean, feel free to add your thoughts there
@midenok cannot say now, sorry. feel free not to work on it now, it won't make it into 10.3.7 anyway

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