[Akonadi] [Bug 336582] Sudden write interruption during akonadictl vacuum causes database corruption

[Daniel Vrátil]

https://bugs.kde.org/show_bug.cgi?id=336582

Daniel Vrátil <dvratil at redhat.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
                 CC|                            |dvratil at redhat.com
         Resolution|---                         |INVALID

--- Comment #1 from Daniel Vrátil <dvratil at redhat.com> ---
There's very little we can do during power-loss or kernel panic. Also this is
obviously not an Akonadi problem, but a MySQL and Btrfs one, as you explicitly
mentioned database corruption while running Btrfs.

The reality is, that even when kernel requests fsync, many modern HDDs
(especially in laptops) will report the data as written, while in fact they
will keep them in internal memory and schedule for writeback later, potentially
leading to data corruption on power loss.

Per documentation of innodb_flush_log_at_trx_commit:
....
A value of 1 is required for ACID compliance. You can achieve better
performance by setting the value different from 1, but then you can lose at
most one second worth of transactions in a crash. With a value of 0, any mysqld
process crash can erase the last second of transactions. With a value of 2,
then only an operating system crash or a power outage can erase the last second
of transactions. However, InnoDB's crash recovery is not affected and thus
crash recovery does work regardless of the value. 

Losing "up to last second of transactions"  can only result in Akonadi cache
being inconsistent with server data and which should be automatically fixed
during next sync. This does not lead to database (table datafile) corruption.

Same applies for sync_binlog - it does not affect the table datafiles, only
journals.

-- 
You are receiving this mail because:
You are the assignee for the bug.