NOV
13
2011
|
Akonadi misconception #1: where is my data?I regularly see the same misconception and fear popping up on the mailing lists, bug reports and IRC: if the Akonadi database gets corrupted, I will lose my data. To make it clear from the beginning: the Akonadi database is NOT your MAIN data storage. So what is the database? 1) It is an interface: the Akonadi server and the underlying database is a common interface to your (PIM-alike) data for different applications, so those applications do not have to deal with the data files directly. 2) But I see my email headers and even the body in the database and in $HOME/.local/share/akonadi/file_db_data. Why? Because the database is also a cache towards your data. Common, frequently accessed parts (like e-mail headers) are stored in the database. These are usually stored permanently and kept in sync with your original data source (IMAP folders, mails on the local disc). 3) Is there anything I might lose by deleting the database? Yes, there is, and that is the metadata added to your data. That can be anything extra information that cannot be stored in the format of your data, like Nepomuk tags or other custom information. In case of emails, you might think that read/forwarded/etc. can be lost. Luckily this is not the case (since KDE 4.7.2), as the email storage formats can store these informations natively. The above explains why you will not lose any critical information by losing your akonadi database. Good, but where is my data if not in the database? This depends on what kind of data we are talking about. 1) E-mail: in case of IMAP (online or disconnected) your data is on the IMAP server. With disconnected IMAP there are windows when your local cache contains data that is not yet syncronized to the server, deleting the local cache in this case indeed will make you lose the unsynchronized files. This is not Akonadi specific though, this is true for any disconnected IMAP client. 2) Calendars and contact information: they can be either on a server (Kolab server, LDAP server) and only cached in Akonadi as explained, or they can be in local vcard or .ics file. The actual location of these files again depends on your setup. The new standard place for them is $HOME/.local/share/contacts. Still there were reports of data losing, why? Unfortunately programmers are not perfect and introduce bugs in the codebase. One of the most severe bugs caused real data losing when copying mails from one folder to another. This is fixed with KDE 4.7.2+ and any recent Akonadi server. There are other bugs around, but none will cause losing your original data files. Finally, what will happen if the database gets corrupted? Of course, it needs to be recreated. You can try by shutting down akonadi server (akonadictl stop), removing the $HOME/.local/share/akonadi and syncronize all your resources again (this will take some time). If the database is not recreated, you need to do a full cleanup by removing also the configuration files under $HOME/.config/akonadi. I hope this will clear some confusion about the data storage inside Akonadi. And a few word about the database itself. What about other database backends? There were plans to use Virtuoso, to reduce the number of database severs needed for a KDE desktop, but the work was not completed. See the techbase aritcle. UPDATE: Christophe Giboudeaux raised a point about PostgreSQL, that their database format changes between major releases in an incompatible way and there is no automated, easy way for upgrade (you need to dump it with the old version and import with the new one). Sad, that there is no perfect solution. |
![]() |
Comments
upgrading mysql for akonadi
I am getting a lot if errors in the log. mariadb 10.xx.xx has a different structure than the version before. The problem is to solve it by running upgrade. I did by doing mysql_upgrade -p
but that doesn't upgrade mysql akonadi is using. How should that be done?
Where is my data?
When Kmail2 from KDE 4.14.3 imports emails from Sylpheed mail-dir, it stores the emails in the database .local/share/akonadi/file_db_data
In my case it has imported 1Gbyte of emails and froze the system for the next two hours until I decided to reset it. akonadi/file_db_data is now 1.27Gbyte and Kmail2 provides no option for extracting the emails from the database. And Kmail2 gives no hint that the imported mail is now in the akonadi database instead of a mail directory.
Cleaning the cache
Hi amantia, and thanks for clearing this up.
You say: "technically it is possible to configure when the cache is cleaned or if it is cleaned at all, but the regular user should not have to deal with it".
My question is--how? My .local/share/akonadi directory is 1.3 GB, too much considering my need is caching just the last few mails I read. I didn't find any way to clean the cache or control its settings. Is it indeed possible for the end user to have such a control?
Thanks & Regards
what about Frameworks versions
Will this page (and other related pages about akonadi) get updated or replaced to refer to the Frameworks versions of things?
mysql nfs mounted
I configured two lInux boxes using a common nfs mounted folder to share my desktop and home directory.... But I Lost all my knotes data because of mount dismount and accessing my home directory remotely.... It was very bad...
Pages