Getting MySQL Service Running Again After Yum Update
Being a fan of staying on top of the latest technology I was excited when I saw that WordPress 3.2 had been released. Not only from a functionality point of view, but a security one too. It boasted many improvements that I was keen to get my hands on.
Upon going to update WordPress I discovered that my version of PHP was too old and that I needed to upgrade to PHP 5.2.4. I’d never done a PHP update before but after a little time spent searching (and building up the courage) I managed to perform the upgrade by following the instructions provided by Jason Litka here.
All in all the update seemed to go as planned and as described in the instructions, however when I then went to visit any of my sites I was getting MySQL errors about not being able to connect to the MySQL server. I booted up Plesk and it seemed that the MySQL service was not running. I was unable to start the service using plesk or via the command line using the following command:
‘FAILED’ was the reponse. Not a very helpful response albeit but solid confirmation that something wasn’t right here. Checking the MySQL log was my next step to see if I could find a more helpful explanation as to the cause of the problem. I opened the log by using the following the command:
Note that the path above may differ based on what’s stated in your MySQL configuration file.
At the very bottom of the log was the following output:
090701 19:10:48 mysqld started 090701 19:10:49 InnoDB: Database was not shut down normally! InnoDB: Starting crash recovery. InnoDB: Reading tablespace information from the .ibd files... InnoDB: Restoring possible half-written data pages from the doublewrite
Again, this didn’t prove very helpful at first glance but it was clear that something wasn’t quite right with the setup since the update.
Finally, after much time trying to figure out the issue I had got it. Allow me to explain…
Located on the server is a file called my.cnf that stores all the configuration options that relate to the MySQL service. Upon performing the update the original my.cnf file was not updated, but instead a new version was created called my.cnf.rpmnew. I compared these two files and saw the following:
[mysqld] datadir=/var/lib/mysql socket=/var/lib/mysql/mysql.sock user=mysql # Disabling symbolic-links is recommended to prevent assorted security risks symbolic-links=0 # To enable the InnoDB Plugin, uncomment the 2 next lines #ignore-builtin-innodb #plugin-load=innodb=ha_innodb_plugin.so # To enable InnoDB-related INFORMATION_SCHEMA tables # Join the following options to above directive ;innodb_trx=ha_innodb_plugin.so ;innodb_locks=ha_innodb_plugin.so ;innodb_cmp=ha_innodb_plugin.so ;innodb_cmp_reset=ha_innodb_plugin.so ;innodb_cmpmem=ha_innodb_plugin.so ;innodb_cmpmem_reset=ha_innodb_plugin.so [mysqld_safe] log-error=/var/log/mysqld.log pid-file=/var/run/mysqld/mysqld.pid
[mysqld] set-variable=local-infile=0 datadir=/var/lib/mysql socket=/var/lib/mysql/mysql.sock user=mysql # Default to using old password format for compatibility with mysql 3.x # clients (those using the mysqlclient10 compatibility package). old_passwords=1 skip-networking skip-bdb set-variable = innodb_buffer_pool_size=2M set-variable = innodb_additional_mem_pool_size=500K set-variable = innodb_log_buffer_size=500K set-variable = innodb_thread_concurrency=2 [mysqld_safe] log-error=/var/log/mysqld.log pid-file=/var/run/mysqld/mysqld.pid skip-bdb set-variable = innodb_buffer_pool_size=2M set-variable = innodb_additional_mem_pool_size=500K set-variable = innodb_log_buffer_size=500K set-variable = innodb_thread_concurrency=2
As you can see the two differ quite a bit. To sort the issue I simply renamed the new version to be the same as the original like so:
mv my.cnf.rpmnew my.cnf
Holding my breath I attempted to start the MySQL service again and it fired right up bringing all my sites back to life.