Sergey Petrunia <sergey@mariadb.com> writes:
* innodb_flush_log_at_trx_commit. Currently, Akonadi uses innodb_flush_log_at_trx_commit=2 which as far as I understand can cause up to 1 second of changes to be lost. Using value of 1 (always flush on commit) should be safer, but maybe it would put an unnecessary load on the system? Akonadi's use case has a bit different idea of what load is - there is only one person making changes, but the system is likely to be a laptop where one cares about battery life, etc.
innodb_flush_log_at_trx_commit=2 can lose up to 1 seconds of changes, yes, but this only happens if the kernel crashes (kernel bug or power failure). If mysqld crashes, there is no data loss. Presumably power failure is less likely on a laptop due to the battery. But note that this is probably irrelevant for laptop usage. On a laptop, the disk will almost invariably be configured with cache enabled. This means that the disk will lie to the operating system about fsync(), claiming that data is synced durably to disk when it is not. This will invalidate any durability guarantees that InnoDB tries to make. In fact, it even destroys crash-safety of InnoDB, meaning that a power failure can corrupt InnoDB data to the point where recovery is not possible except by complete restore from backup. - Kristian.