MySQL Server Update Today, No Downtime

I use the home-computer I name ‘Phoenix’ as my Web-server. This means that I’m always looking for ways to complete routine system updates, without wanting my server to go offline, as my server going offline would also mean, that for several minutes, my site is not accessible to the public. My server would go offline for a few minutes, if I simply needed to reboot it.

Today came another time, when an update to my MySQL (Database-) Server became due. I have two instances of MySQL running:

  1. As a system process, which serves my Web-site and blog,
  2. As a user-process, which serves the desktop-PIM-daemon also known as “Akonadi”.

Simply having installed the MySQL update, will assure that the system-process is also restarted. But it will not assure, that the user-process is also restarted.

In such cases, what I can often do, is, after the update is finished, Log Out my user-session, and Log it back In. Doing so does not fully reboot the computer, but just restarts the user-space processes, which make up my session, including Akonadi, and including that MySQL user-process.

Today, after the update itself, I performed such a log-out-followed by the log-in. What this means is that my Web-site should have remained accessible the whole time. Yay!

This was the last time, I had accomplished the same thing.



New MySQL Update Breaks Akonadi, Unless ‘mysql-server’ Is Installed.

The way PIM (Personal Information Management) works under KDE, is that it has a server called the ‘Akonadi Server’, which provides back-ends that allow the desktop system to synchronize with other applications.

For example, I use it to synchronize my desktop calendar with Google Calendar.

In order for Akonadi to work, it creates a MySQL database-engine instance, in the personal folders of one user – i.e. in user-space. This is remarkable, because ordinarily, the MySQL server is supposed to run as a system process, which means that any user needs a database user-name and password, even to connect to the MySQL server on his own machine. But Akonadi has sidestepped this need, by allowing a separate instance of the server-process to run entirely in his user-name.

What this used to mean for package-dependencies, is that a computer was allowed only to have ‘mysql-core‘ and ‘mysql-client‘ installed, without having to have ‘mysql-server‘ installed, as the binaries can be pulled in without the ‘mysql-server‘ package, the latter of which merely used to enable the (system-wide) daemon.

Well, the latest MySQL update ran perfectly on my server-box ‘Phoenix’, because this machine already had the system-wide server process installed and operational.

But on my laptop named ‘Klystron’, Akonadi would not start, since the latest MySQL update. In obscure, buried error messages, it would complain that the directory ‘/var/lib/mysql-files‘ could not be accessed.

BTW, MySQL does not run as root, but rather under user-name ‘mysql‘.

After an hour of work on my laptop I discovered that the newer MySQL versions will not run the server-process at all – not even the way Akonadi configures it – unless we also have the package ‘mysql-server‘ installed. Installing this package finally allowed Akonadi to start again. Doing so will firstly define the user-name ‘mysql‘, and secondly create the needed directory, belonging to that user-name.

It might help some other people to know this, before they wipe their Akonadi database directory. My favorite way to fix Akonadi errors was just to wipe it, but this time that solution would not work.

Also, once I had created the MySQL server as a system service, I had to assign an initial root password for it. But I never had to enter that system password, in order for Akonadi to work again. If the system DB was being used, that would not be possible, because any user process would first need a user DB, and a user DB password, which would require that the root credential be entered to accomplish.


(Edit 11/15/2016 : ) Given the latest update to Akonadi, by KDE developers, this issue may have been fixed.