maria-developers team mailing list archive

[Zardosht Kasheff <zardosht@xxxxxxxxx>]

Hello all,

I am investigating what our storage engine, TokuDB, needs to do to
achieve its best performance in MariaDB 5.5 with respect to preparing
and committing transactions, and with respect to binary logging.

As I understand, group commit has been added to the binary log in
Maria 5.3, and is also in MariaDB 5.5. Additionally, new APIs
prepare_ordered and commit_ordered are added.

I am trying to understand how these fit together.

>From reading http://kristiannielsen.livejournal.com/12408.html and
comments in handler.h, here is what I THINK I know:
 - In MariaDB 5.5, we must fsync our recovery log on
handlerton->prepare and handlerton->commit
 - If we want to ensure that the order we commit transactions is the
same order that they appear committed in the binary log, then we
should perform our commit in two phases, commit_ordered and commit,
where commit_ordered is serialized under a global mutex that ensures
the correct order
 - InnoDB must do this for hot backup to work

Here is my big question: given TokuDB is not designed to work with
InnoDB's hot backup solution, is there ANY reason why we should care
about the commit order of our transactions? Are there any performance
reasons related to group commit?

>From everything I read, I think the answer is no, but I would
appreciate confirmation. I think there are no performance gains to be
made by implementing commit_ordered, and given we fsync on commit,
there should be no issues with syncing our engine up with the binary
log after a crash.

Also, I assume the fsync after commit is necessary. Only in 10.0 will
some new functionality be available that allows us to not fsync on
commit.

Is my understanding correct?

Thanks
-Zardosht