Re: Frequent coruptions of data base. Any remedies?
Andras Mantia <[email protected]>
| Newsgroups | gmane.comp.kde.users.pim |
|---|---|
| Message-ID | <[email protected]> |
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