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.