Upgrading directly from MySQL 5.1 : The server quit without updating PID file

I ran across this the other day...

System was a very basic Oracle Linux install that was installed and created by someone else.
( Oracle Linux Server Unbreakable Enterprise Kernel (2.6.39-400.17.1.el6uek.x86_64) )
It appeared that they wanted the system up and running then have me come in to do the rest.

By the way, if Oracle is going to take RedHat Linux and enhance it to make their own version, could they at least update their products to work with it? MySQL became popular because it was easy for people to get from the distributions, having 5.1 still in their own distribution is just odd.

Well the first thing to do is upgrade since Oracle Linux comes with MySQL 5.1.

# rpm -qa |grep mysql
mysql-server-5.1.66-2.el6_3.x86_64
mysql-5.1.66-2.el6_3.x86_64
mysql-libs-5.1.66-2.el6_3.x86_64



I used 5.5 for this example....

-rw-r--r--. 1 root root 14976016 Apr 30 06:07 MySQL-client-5.5.31-2.el6.x86_64.rpm
-rw-r--r--. 1 root root  4968092 Apr 30 06:08 MySQL-devel-5.5.31-2.el6.x86_64.rpm
-rw-r--r--. 1 root root 41827172 Apr 30 06:09 MySQL-server-5.5.31-2.el6.x86_64.rpm
-rw-r--r--. 1 root root  3970056 Apr 30 06:09 MySQL-shared-compat-5.5.31-2.el6.x86_64.rpm


# rpm -Uhv *.rpm
error: Failed dependencies

So I had to remove the dependency packages first, and not even sure why that really had them installed. 

# rpm -Uhv *.rpm


Now you comes the sad fact that many of us have seen...

"A manual dump and restore using mysqldump is recommended.

A manual upgrade is required.

- Ensure that you have a complete, working backup of your data and my.cnf

  files

- Shut down the MySQL server cleanly

- Remove the existing MySQL packages.  Usually this command will

  list the packages you should remove:

  rpm -qa | grep -i '^mysql-'

  You may choose to use 'rpm --nodeps -ev <package-name>' to remove

  the package which contains the mysqlclient shared library.  The

  library will be reinstalled by the MySQL-shared-compat package.

- Install the new MySQL packages supplied by Oracle and/or its affiliates

- Ensure that the MySQL server is started

- Run the 'mysql_upgrade' program " 

This is why so many people could be stuck in MySQl 5.1 because they are scared to death to make these changes.  I was lucky since this was a fresh install otherwise yes keeping a backup would be the next step. 

Since it wanted me to remove everything, then no reason to say with MySQL 5.5 so I moved to MySQL 5.6.  After removing the previous packages (rpm -e) and installing the new (rpm -ihv),  I had the following

# rpm -qa | grep MySQL
MySQL-client-5.6.11-2.el6.x86_64
perl-DBD-MySQL-4.013-3.el6.x86_64
MySQL-shared-compat-5.6.11-2.el6.x86_64
MySQL-server-5.6.11-2.el6.x86_64
MySQL-devel-5.6.11-2.el6.x86_64



So I check for a my.cnf file first. Since I might want to make edits if someone had placed on in place.

# ls -al /etc/my.cnf
ls: cannot access /etc/my.cnf: No such file or directory

I decide to keep to defaults for the purpose of this example and I left it missing.

# /etc/init.d/mysql start
Starting MySQL..The server quit without updating PID file ([FAILED]/mysql/localhost.localdomain.pid).

It does have to be able to start before mysql_upgrade can be applied. 

I tried skip grants

#  /etc/init.d/mysql start --skip-grant
Starting MySQL..The server quit without updating PID file ([FAILED]/mysql/localhost.localdomain.pid).


In reality the error log showed the true issue : "InnoDB: Could not open or create the system tablespace"

The issue was they built the partitions horrifically and just had no space for the database.  When should you realize this ? Right away. First thing you should do is to check what the partitions of the system are for a system you are building. But that would void the point of this blog post if I pointed that out first. 

What is the moral of all this? If you ever see the error "The server quit without updating PID file " the very first thing you should do is check the error log. It will tell you exactly what the problem is.