Re: question on storage engines, two phase commits, and fsyncing on commit

Kristian Nielsen <[email protected]>
Newsgroups gmane.comp.db.mysql.devel
Message-ID <[email protected]>
Sergei Golubchik <[email protected]> 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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.