[kdepim-users] changing database backend
pablo at blueoakdb.com
Wed Nov 12 14:54:20 GMT 2014
[ Comments below, in-line ]
On 11/12/2014 09:11 AM, René J.V. Bertin wrote:
> I must have been unclear - my idea of changing concerned my Linux
> rigs because those run on ZFS. You're undoubtedly aware that you
> disable COW on btrfs (I suppose for performance reasons). That's
> highly "not done" on ZFS and thus impossible, but also much less
> necessary because of internal optimisation (or so I have been told).
> Either way, it makes sense to disable COW-like features in software
> when it write to a filesystem that already implements it. MySQL
> allows that by setting innodb_doublewrite=0 . I'd compare the other
> option but 1) I'd have to start the server myself and 2) no way if
> I'd have to redo the whole of akonadi again...
If you're willing to /potentially/ compromise data integrity, you can
disable database logging (to some extent). Except for the hardest of
hardware failures, you'll /probably/ be okay.
Another way to say this, if you're willing to tolerate some data loss
and/or database inconsistency, then disable logging. I wouldn't do
it. I'd rather buy an SSD (cheap!) and not worry about I/O.
The documentation for /innodb_doublewrite/ parameter explicity states:
This variable can be turned off with --skip-innodb_doublewrite for
benchmarks or cases when top performance is needed rather than
concern for data integrity or possible failures.
In order for the DBMS to conform to ACID , you can't disable
If you want more information about MySQL and the ACID Model, see this
... you can adjust MySQL settings to trade some of the ACID
reliability for greater performance or throughput.
 - http://en.wikipedia.org/wiki/ACID
Pablo Sanchez - Blueoak Database Engineering, Inc
Ph: 819.459.1926 Blog: http://pablo-blog.blueoakdb.com
KDE PIM users mailing list
Subscription management: https://mail.kde.org/mailman/listinfo/kdepim-users
More information about the kdepim-users