maria-developers team mailing list archive
Mailing list archive
Re: commit performance when the binlog is enabled
On Dec 29, MARK CALLAGHAN wrote:
> On Mon, Dec 28, 2009 at 9:20 AM, Sergei Golubchik <sergii@xxxxxxxxx> wrote:
> > trn1> start transaction; insert t1 select * from t2;
> > trn1> commit;
> > trn1>> ... xa_prepare() ...
> > trn2> start transaction; insert t2 values (1); commit;
> > trn2>> xa_prepare(); binlog.write(); xa_commit();
> > trn1> ... binlog.write(); xa_commit();
> > and you have incorrect transaction order in binlog.
> There are several issues here:
> * for SBR, tm1 cannot release row locks until it is guaranteed that it
> writes the binlog ahead of any dependent transactions. This is
> guaranteed by locking prepare_commit_mutex at the end of
> innobase_xa_prepare and not unlocking until row locks are released
> during the call to innobase_commit.
I don't see what prepare_commit_mutex has to do with it. It is
guaranteed by row locks released at commit time, no matter whether
prepare_commit_mutex exists or not.
> * at least for the plugin the order in which InnoDB prepare is done
> might not match the order in which transactions are written to the
> binlog. InnoDB locks prepare_commit_mutex in innobase_xa_prepare after
> doing a prepare (the call to trx_prepare_for_mysql). It is unlocked
> after the commit record is written to the InnoDB transaction buffer
> and before that buffer is flushed to disk. What does match today is
> the order of transactions in the binlog and the commit records in the
> InnoDB transaction log.
Yes, and this is what prepare_commit_mutex is for.
Regards / Mit vielen Grüßen,
__ ___ ___ ____ __
/ |/ /_ __/ __/ __ \/ / Sergei Golubchik <serg@xxxxxxx>
/ /|_/ / // /\ \/ /_/ / /__ Principal Software Engineer/Server Architect
/_/ /_/\_, /___/\___\_\___/ Sun Microsystems GmbH, HRB München 161028
<___/ Sonnenallee 1, 85551 Kirchheim-Heimstetten
Geschäftsführer: Thomas Schroeder, Wolfgang Engels, Wolf Frenkel
Vorsitzender des Aufsichtsrates: Martin Häring