Multiple rows are recovered

Bug #1025164 reported by Aleksandr Kuzminsky on 2012-07-16
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Percona Data Recovery Tool for InnoDB
High
Unassigned

Bug Description

It's possible a situations when a rows with the same PK can be found multiple times in the recovered dump.
All those have the same PK values, but different trx_id. However trx_id is not a part of the dump (TRX_ID is internal field).
Thus, there is no way to distinguish the rows with the same PK.
Obviously, the row with the biggest trx_if must be uploaded to the recovered database, but this is not guaranteed now.
If there are several rows in the dump with the same PK, eventually the last one will show up in MySQL (because the rows are loaded with LOAD DATA INFILE REPLACE command)

There should be any means to control which version of the row must be imported into MySQL.

possible trx_id should be a part of the dump

Changed in percona-data-recovery-tool-for-innodb:
importance: Undecided → High
assignee: nobody → Aleksandr Kuzminsky (akuzminsky)
Changed in percona-data-recovery-tool-for-innodb:
milestone: none → release-0.6
status: New → Confirmed

Transaction id and rollback pointer are prefixed now before every line:

000000001416 D90000015B0110 actor 1 "PENELOPE" "GUINESS" "2006-02-15 04:34:33"
000000001416 D90000015B011B actor 2 "NICK" "WAHLBERG" "2006-02-15 04:34:33"

000000001416 is the trx_id.
If necessary the records can be sorted with "sort -n" or "sort -rn" and loaded into MySQL.
A version of the record appeared in a dump last will get into the table eventually.

Changed in percona-data-recovery-tool-for-innodb:
status: Confirmed → In Progress
Changed in percona-data-recovery-tool-for-innodb:
assignee: Aleksandr Kuzminsky (akuzminsky) → nobody
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers