Hi, MARK!
On Dec 29, MARK CALLAGHAN wrote:
> On Tue, Dec 29, 2009 at 11:23 AM, Sergei Golubchik <ser...@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 <s...@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
_______________________________________________
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
