maria-developers team mailing list archive

[Kristian Nielsen <knielsen@xxxxxxxxxxxxxxx>]

Marko Mäkelä <marko.makela@xxxxxxxxxxx> 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.