Delete comment from: MySQL Musings
Mats, xtrabackup/innobackup does not look at the binlog at all, they only copy
innodb transaction logs and tablespaces directly from disk. This is for the
non-blocking operation, there are scripts on top which do FLUSH TABLES WITH
READ LOCK, but then the backup can block the server arbitrarily long depending
on worklog.
Suppose we are committing transactions A,B,C,D,E.
Without controlling commit order, it can happen that when we take the
non-blocking {inno,xtra}backup we have:
- Binlog contains transactions A,B,C,D (in this order).
- InnoDB backup has transactions B,D committed, A,C,E prepared.
How are you going to restore the backup? There is no point in the master
binlog corresponding to only B and D committed. You need to know somehow to XA
commit A and C and XA rollback E (ie. effectively run the XA recovery at
restore time).
My question is, how do you handle this? The MariaDB group commit avoids this
by ensuring that InnoDB commits in the order A,B,C,D,E like the binlog, so
backup snatshots can never see (B,D). If you do not do this, do you then
extend innoback to also copy the binlogs and run XA recovery?
Aug 12, 2011, 8:33:41 AM
Posted to Binlog Group Commit Experiments