[prev in list] [next in list] [prev in thread] [next in thread] 

List:       mysql-internals
Subject:    Re: question on storage engines, two phase commits, and fsyncing on commit
From:       Kristian Nielsen <knielsen () knielsen-hq ! org>
Date:       2012-04-15 8:17:32
Message-ID: 87obqt1k9v.fsf () frigg ! knielsen-hq ! org
[Download RAW message or body]

Sergei Golubchik <serg@askmonty.org> 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.

-- 
MySQL Internals Mailing List
For list archives: http://lists.mysql.com/internals
To unsubscribe:    http://lists.mysql.com/internals

[prev in list] [next in list] [prev in thread] [next in thread]