Gordan Bobic <[email protected]> writes: > On Tue, 10 Feb 2026 at 15:34, Kristian Nielsen <[email protected]> > wrote:
>> It should be enough to run with innodb_flush_log_at_trx_commit=2 and >> sync_binlog=0 to have consistent snapshots. In this case, the data is > Right, but what happens in the following scenario: > 1) Transaction arrives > 2) Transaction gets written to the redo log > 3) Transaction gets written to the binlog > 4) Before the flush is issued a second later on the innodb log, the > OS' disk I/O scheduler decides to write the binlog before flushing the > redo log to stable storage > 5) Power outage / hard kernel crash happens > > Without write ordering guarantees, this will lead to an inconsistent > state on disk at a lower layer. Absolutely. To recover InnoDB+binlog consistently after a kernel crash requires --sync-binlog=1 and --innodb-flush-log-at-trx-commit=1 in the existing binlog. (The new binlog implementation that's in 12.3 doesn't have this requirement incidentally). My point was that in the backup scenario - assuming the kernel doesn't crash during the backup - the snapshot should be consistent without the fsync to disk, the write to the kernel buffers is enough. - Kristian. _______________________________________________ discuss mailing list -- [email protected] To unsubscribe send an email to [email protected]
