From: Kristian Nielsen
Date: January 31 2013 9:41am
Subject: Re: reducing fsyncs during handlerton->prepare and handlerton->commit in 5.6
List-Archive: http://lists.mysql.com/internals/38708
Message-Id: <87d2wllmfi.fsf@frigg.knielsen-hq.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

Mats Kindahl <mats.kindahl@stripped> writes:

> In MySQL 5.6, there are no new APIs that you *have* to comply with.

But MySQL 5.6 serialises calls to the commit handlerton method, the next one
cannot start before the previous one completes. So if you did fsync() with
group commit before in commit, your group commit will no longer work in 5.6
and you will get a serious performance regression if you do not honour the
HA_IGNORE_DURABILITY flag. I consider that breaking the storage engine API, as
you see Mats and I disagree a bit on that point :-)

Anyway, it should be easy to do for you. MySQL 5.6 sets HA_IGNORE_DURABILITY,
this has similar semantics to when MariaDB 5.3+ calls the commit_ordered()
method. So you can probably use the same code for both with a small amount of
#ifdef.

Note that for MySQL 5.6 you need to implement also the flush_logs() method to
fsync() all prior commits durably to disk (if you did not already implement
it). What happens is basically that in MySQL crash recovery looks only at the
last binlog file written. So it calls flush_logs() before creating a new
binlog, and storage engine must ensure that all commits become durable at that
point. Otherwise commits may be lost if a crash happens just after binlog
rotation.

This is actually the _only_ reason that fsync() was ever needed in commit, to
ensure that it is done when binlog is rotated. So it is rather silly that we
have done it for _every_ commit for so long. Anyway, it will be fixed now.

 - Kristian.