On Tue, Dec 29, 2009 at 11:23 AM, Sergei Golubchik <ser...@pisem.net> wrote: > Hi, Paul! > > On Dec 29, Paul McCullagh wrote: >> On Dec 26, 2009, at 3:40 AM, MARK CALLAGHAN wrote: >> >>> * InnoDB locks prepare_commit_mutex in the prepare step >> >> What is the purpose of this lock? > > As far as I understand (disclaimer!), it's purpose is to ensure that > commit records in the InnoDB transactional log are written in the same > order as Xid events in the binlog. > > And the only reason for enforcing this order - as far as I understand - > is innodb hotbackup. It reads InnoDB logs (as files) and grabs a copy of > the binlog. And after recovery all data must be consistent. If binlog > contains more transactions that innodb logs, it's no problem - binlog > can be truncated. But at no point binlog can have *less* transactions. > > If prepare_commit_mutex is removed, I can create an ordering of commits > where innodb log *always* has committed transactions that are not in a > binlog.
Is this a potential problem? * order of transactions in binlog don't commit record order for InnoDB in transaction log * binlog rotation occurs * last binlog has XIDs 1, 3, 5 * current binlog has XIDs 2, 4 * server crashes * XID 5 is in state PREPARED (not committed) before the crash If crash recovery uses the latest binlog then it won't know to rollback XID 5 during crash recovery. I thought someone explained to me the constraints on binlog rotation that might be related to this, but I don't remember the details. -- Mark Callaghan mdcal...@gmail.com _______________________________________________ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
