I don’t know why I thought using the Percona MySQL server was a good idea. I was going through the Ubuntu Server Guide and saw the Percona configuration tool.
I should have known better than to keep pursuing this “enhancement” when the configuration file didn’t work. But I didn’t, and after a few weeks of fighting it, I decided to go back to the plain Jane MySQL server distributed through the Ubuntu repositories.
Reverting to the standard MySQL server turned out to be easier said than done. The Percona enhancement fights tooth and nail to keep running on your system, but there’s a simple way to kill it.
The Reincarnating “mysqld”
I’m not sure exactly what causes this to happen, but I found myself in this situation twice on the Dell PowerEdge 750 servers I’ve been working on. When I tried to uninstall Percona and reinstall the normal MySQL server package, the system would fail to stop the Percona server.
Some forums and posts online recommend using the kill command to manually stop the process. You can find the process ID number with this command: ps -A | grep 'mysql'. When you have the right process ID, you should be able to kill it with this: sudo kill -9 [process ID #].
In my experience, that trick worked in killing the MySQL server. But it didn’t keep the server from coming back to life immediately, this time on a new process ID number.
No matter how many times I tried this method, the “mysqld” process just kept coming back and I couldn’t remove the Percona server.
How to Kill “mysqld”
I spent the better part of the afternoon trying different variations of apt-get commands, Aptitude package management, and kill commands until finally the other guy found a solution.
sudo stop mysql
These three words were all it took.
I was then able to remove Percona and reinstall the default MySQL server.
What usually causes this to happen is having a previous install of MySQL on the system, and then migrating to Percona Server. When the MySQL package provided by the distro is uninstalled, some of its files are neither removed, nor renamed, effectively leaving a broken system.
In this case, a /etc/init/mysql.conf file remains, instructing upstart to automatically start mysql when the net comes up, the local filesystems are mounted, and the runlevel is any of 3, 4, 5 or 5. So no matter how often you kill mysqld, upstart will start it again.
If ‘sudo stop mysql’ worked for you, this means that upstart was able to find the ‘mysql’ service. Since AFAIK Percona does not ship a /etc/init/mysql.conf file, this means the file must have been installed by the distro’s own mysql package.