On Tue, Dec 29, 2009 at 11:23 AM, Sergei Golubchik <sergii@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 mdcallag@gmail.com