Autostart MySQL After a Crash : Solve WordPress Database Connection Error

WordPress Error establishing a database connection is frequently faced problem. In our previous guides, we pointed to properly configure my.cnf, that is adding [mysqld_safe] stanza at the end of my.cnf file with socket, PID. For newer versions of MYSQL, we written guide for Percona MySQL to auto-restart. Newer Ubuntu, Debian installations do not automatically create the required debian-sys-maint user for restart. In that installation guide, we tried address it. However, still MySQL may fail to auto restart after a crash! Here is one fallback way to autostart MySQL after a crash.

Autostart MySQL After a Crash : Reasons of Failure

Unfortunately, MySQL may start to fail depending on the error the crash happened!. In the above paragraph, we described one type of errors in configuration and absense of the required user to execute the work.

Corrupt MySQL binary can cause the MySQL server to fail. Ownership and permissions of the MySQL files such as binaries, logs may get itself changed during a version upgrade, which may lead to errors. The /tmp directory should be checked for permission, space. Lack of disk space, not enough memory may fail the automatic restart process. A badly coded WordPress plugin may create odd situation. Self hosted analytics plugins may invite trouble.

Autostart MySQL After a Crash : Fallback Bash Script and Cron

Depending upon your situation, a fallback bash script and cron job to execute the script may act as additional layer for peace when chance to manually check the site too longer! You’ll notice during upgrades that Percona identifies ownself as :

That often create confusion during complete removal (for re-installation). However, general purpose command :

… works for all kind of MySQL forks. Compare the difference after running the above and below commands :

If you run :

You’ll get response like below :

This symlink to MySQL’s init script in the /etc/rc2.d directory. The S script under the default runlevel directory for the service, init will start the service when the server will be rebooted. Manual reboot of server from mobile devices can be an emergency life-saver in acute emergencies.

Now run these commands :

You’ll get output something like :

The number beside the username is PID. mysqld_safe and mysqld. mysqld_safe has process IDs 29795 and 30182 respectively. We can kill them to emulate crash :

Now, if you run :

You’ll get MySQL is stopped.. message. Of course you can get rid of test crash to normal situation by the command :

You can check by running :

Now if we create a bash script named safe.sh kept on my GitHub repo and then make it executable :

Then, executing the script should restart MySQL after simulating crash :

It will brutally start MySQL. If a service does not exist, we can start by adding and entry on cron (sudo crontab -e), like for example service named nothing.service (it is every minute checking for example) :

Instead of nothing.service, using mysql.service should start MySQL. Easy way to remember cron :

Where :
1 -> Minute (0-59)
2 -> Hours (0-23)
3 -> Day (0-31)
4 -> Month (0-12 [12 == December])
5 -> Day of the week(0-7 [7 or 0 == sunday])
/root/script.sh – Script with path

If that normal restart fails then try that bash script :

If the /bin/systemctl status mysql.service || logic fails then you need another bash script to curl, cut, grep “eroor database” like keyword from home page and fire it. Now various methods will be timed in a way that no method keeps server down for more than 30 minutes.