List:Internals« Previous MessageNext Message »
From:Kristian Nielsen Date:April 15 2012 8:17am
Subject:Re: question on storage engines, two phase commits, and fsyncing on commit
View as plain text  
Sergei Golubchik <serg@stripped> writes:

> On Apr 14, Zardosht Kasheff wrote:

>> Storage engines that support two-phase commit implement the functions
>> handlerton->prepare and handlerton->commit. Clearly, a storage engine
>> must fsync its own log after handlerton->prepare so that if we crash,
>> it may report the prepared transaction to MySQL via
>> handlerton->recover.
>> 
>> My question is this: Do we need to fsync our log after
>> handlerton->commit, or can we somehow be guaranteed that if we do not
>> fsync, upon a crash, MySQL will have enough information to call
>> handlerton->commit_by_xid on what is a prepared transaction in our
>> storage engine?

> You're absolutely right!
> Indeed, a storage engine is expected to sync both on prepare and on
> commit. You understanding is correct.
>
> But we're going to weaken this requirement in MariaDB (not surprisingly
> :).  We've discussed the solution just about a month ago, and the
> corresponding task is "In Progress". I'll check what's exactly going on

Here is the task:

    https://mariadb.atlassian.net/browse/MDEV-181

The actual design is work-in-progress, and can/will be simplified a lot - but
the basic idea should be there.

Also see the comments on the new prepare_ordered() / commit_ordered()
functions in handler.h. And the worklog:

    http://askmonty.org/worklog/Server-Sprint/?tid=116

 - Kristian.
Thread
question on storage engines, two phase commits, and fsyncing on commitZardosht Kasheff14 Apr
  • Re: question on storage engines, two phase commits, and fsyncing oncommitSergei Golubchik14 Apr
    • Re: question on storage engines, two phase commits, and fsyncing on commitKristian Nielsen15 Apr