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