[kdepim-users] Frequent coruptions of data base. Any remedies?

[Andras Mantia]

Stephan Diestelhorst wrote:

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

Doing anything from akonadi side when the database is corrupted is already 
too late. Best would be if MySQL would be stable enough to deal with such 
cases. This is like trying to recover from a damaged file system.

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

Detecting corruption and informing the user about the problem is a good 
idea, indeed. Can you put the information about the problem with the 
suggestion into bugs.kde.org, so it doesn't get forgotten (not all 
developers watch the user list regularly)? 

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

Interesting, I also have to restart my computers from time to time due to 
failed resume, but never had a problem with the akonadi database. I wonder 
what in the stack is causing the InnoDB instability. I don't use LVM and use 
Ext3/4 though...

> As far as I see, those options for mysql seem to address this, I will
> do some more tests with unclean shutdowns and reboots.

Please add those options to the bug report as well. We can make them the 
default if it turns out to help.

> 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

That's what I tried to do with the blog. I don't really know where we could 
do such education (except catching of course the db failure).

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