Re: Frequent coruptions of data base. Any remedies?

Am Samstag, 12. November 2011 schrieb Andras Mantia:
> Neverthless having a corrupted database is bad, and this being a mysql
> bug  puts us in a bad situation, as MySql is the most tested backend
> and the current default (sqlite is unreliable, postgres might work,
> although it is not that well tested), as makes the applications
> unusable and takes up considerable amount of time (user's time).

Just for the record. I am using Akonadi with a system wide PostgreSQL for 
quite some time now and I didn´t have issues with database consistency. 
But then thats on KDE 4.6.5, 4.7.2 and not 4.7.4 without KDEPIM 2 yet as 
its not yet packaged for Debian.

So its just storing addresses and there I didn´t have issues with MySQL 
either.

I plan to move to a user-specific PostgreSQL before switching to KMail 2 
for various reasons :

1) The database is stored and backed up in the home directory of the user.

2) akonadictl stop should make the data of Akonadi consistent for rsync 
backup *including* the database. Right now I have to akonadictl stop and 
then to stop the system wide PostgreSQL.

Additionally to that I think a scheduled backup utility like the one in 
Nepomuk would be a good idea. It should store the database dump in an 
compressed format tough.

As for MySQL: It would be nice to see whether the additional options help 
to ensure that MySQL holds its database integrity. I do think that when 
MySQL is not fit to ensure database integrity on power losses and crashes - 
given that the write barrier or with newer kernel cache flush stoff is 
working across all layers of the I/O stack - the default for Akonadi 
should be changed to a database that holds it integrity in such cases.

Ciao,
-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7
_______________________________________________
KDE PIM users mailing list
Subscription management: https://mail.kde.org/mailman/listinfo/kdepim-users