Federico Razzoli via discuss <discuss@lists.mariadb.org> writes:

> Recently Laurynas commented this bug and he brought it up on social media:
> https://bugs.mysql.com/bug.php?id=75519

This seems to describe a configuration with
--innodb-flush-log-at-trx-commit=1 and --sync-binlog=0.

The described behaviour is that in case of (kernel) crash, transactions may
be lost because binlog events may be not written to disk prior to the crash,
and then the corresponding prepared transaction in innodb is rolled back.

> Did anyone test whether it is in MariaDB too? If so, which versions?

I did not test, but I assume it will be so. Like described in the MySQL bug,
MariaDB flushes the innodb log at prepare, but not at commit when the binlog
is enabled.

This is intended behaviour, though arguably a somewhat non-sensical
configuration (paying the cost of --innodb-flush-log-at-trx-commit=1 without
getting any durability guarantee).

I'm guessing the intention of the user here is to not really care about the
binlog (not using replication perhaps), but still wants to have it enabled
for debugging or the like? So enabled, but with minimum performance impact
and not caring about losing binlog events?

And then the expectation is that this will not impact durability of
--innodb-flush-log-at-trx-commit=1.

But this is not how it is designed. If a transaction is prepared in innodb
but missing in the binlog, it must be rolled back in innodb, to prevent
inconsistency between binlog and innodb.

If this can be documented better, then that's surely good, of course.

(The situation is worse that described. After the crash, not only can
committed transactions be lost, the binlog and innodb can be out of sync
with each other (transactions committed in InnoDB are missing from the
binlog). This happens if the "commit" in the innodb log got written to disk
prior to the crash but the binlog did not. The --sync-binlog=0 is not a
crash-safe configuration).

Hope this helps,

 - Kristian.