Re: Frequent coruptions of data base. Any remedies?

On 12 November 2011 21:53, Andras Mantia <[email protected]> wrote:
> Stephan Diestelhorst wrote:
>
>> Is there a reason why they are not default? If my email were POP, I
>> would have lost considerable amounts of mail by this.
>
> This is common misconception: losing the akonadi database will NOT lose your
> mails. The database stores two things:
> - it acts as a cache
> - it stores metadata information (tags, extra flags)

Ah. Thanks for the clarification! Sorry for spreading FUD here.

> 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).

Indeed.

>> The MySQL folks suggest to dump the database and manually feeding the
>> data back in there, maybe AKonadi could do that?
>
> Question is, how often? When? And that would double the amount of space you
> need in the $HOME.

Mmhhm, it seems that the idea was that one could dump the data base,
even after it was corrupted and manually feed the data back into a new
copy. But this does not sound very stable, either. Maybe Akonadi could
watch for these errors and indicate to the user that only a cache was
lost and delete and repopulate the database files, if all else fails.

> BTW, is you $HOME on an NFS share? AFAIK that has problems with mysql
> databases especially on suspend/resume.

No, this is on a built-in laptop drive with a LUKS -> LVM -> Reiser
stack. The problem here is the laptop dieing every now and then during
suspend / resume, but I'd still have some sane behaviour in that case.
As far as I see, those options for mysql seem to address this, I will
do some more tests with unclean shutdowns and reboots.

A number of things can be done to address this now:
* educate the user about the situation (i.e., not all of your mail is lost)
* educate / help on how to delete the tables, instead of falling into
the same "trap" over and over again

And some later:
* apply the suggested settings from the InnoDB folks in the
mysql.conf, if they do not have any other impact and help (this is
what I'll test during the next days
* if the settings do not help, whip the MySQL folks ;-) and / or try
out another DB

Stephan
_______________________________________________
KDE PIM users mailing list
Subscription management: https://mail.kde.org/mailman/listinfo/kdepim-users