maria-developers team mailing list archive

[MARK CALLAGHAN <mdcallag@xxxxxxxxx>]

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