21 Feb
2013
21 Feb
'13
5:11 a.m.
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