Gordan Bobic via discuss <discuss@lists.mariadb.org> writes:
Thanks for this. Is there a way to force replay of the entire redo log on an unclean shutdown even if the checkpoint in the redo log says it was flushed to tablespace?
This won't help you if the part of the redo log you need was overwritten by new records due to the cyclic nature of the redo log.
I'm exploring the idea of running datadir on storage that preserves write ordering but runs with the equivalent of nobarrier. It will still flush in the background every X seconds where X is configurable, so I am hoping to use the redo log to keep my data crash-safe even though I am lying about tablespace write flushes, because write ordering will be preserved despite running with the equivalent of nobarrier.
If write-ordering is preserved (but it has to preserved between log writes and data writes as well), then you will be crash-safe, because the situation will be the same as if a full-durable system crashed X seconds ago. You will lose the last X seconds of commit, but data will be consistent, similar to --innodb-flush-log-at-trx-commit=2 (or 0). What goal are you trying to achieve here? Some performance gains, or the ability to use main storage with some non-standard write semantics? You can configure InnoDB to have a huge redo log and perhaps there are also some options to reduce the frequency of checkpoints. That should in practice avoid the problem with needed redo log being overwritten. But it's obviously not something that InnoDB was designed to support. - Kristian.