Hi, MARK! On Dec 29, MARK CALLAGHAN wrote:
On Tue, Dec 29, 2009 at 11:23 AM, Sergei Golubchik <sergii@pisem.net> wrote:
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
No, it's not a problem. Because on recovery MySQL only reads the *last* binlog, it needs to ensure somehow that last binlog has all the information that recovery needs. Currently a simple solution is used - binlog rotation waits for all prepared transaction to commit. That is, you can be sure that last binlog has only XIDs for committed transactions.
I thought someone explained to me the constraints on binlog rotation that might be related to this, but I don't remember the details.
That could've been me :) Regards / Mit vielen Grüßen, Sergei -- __ ___ ___ ____ __ / |/ /_ __/ __/ __ \/ / Sergei Golubchik <serg@sun.com> / /|_/ / // /\ \/ /_/ / /__ 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