Marko Mäkelä <marko.makela@mariadb.com> writes:
Hi Kristian,
I was under the impression that it affects normal InnoDB too. But indeed, it looks like you could be right that it is only affecting Galera.
Right. The idea is that one of these two cases apply: 1. There is 2-phase commit (eg. between InnoDB and binlog). The innodb redo log is synced to disk in prepare, commit_ordered() is called where trx->active_commit_ordered is set, and we skip syncing to disk in commit (because we ca recover from the prepared transaction). 2. There is no 2-phase commit (eg. binlog disabled). Prepare / commit_ordered() is not called, trx->active_commit_ordered is not set, log is synced to disk during commit. It sounds like Galera somehow disables the recovery step of (1) (otherwise it would not see the transaction lost). Maybe that is the problem. Or if Galera really doesn't want to recover lost transactions from binlog, maybe it shouldn't do the prepare step (which is costly due to fsync()), not the commit_ordered(). That will break the synchronisation between commit order in binlog and innodb, but I think Galera is already breaking that severely. But yes, something for Galera people to look at. Thanks, - Kristian.