Bobcares

MySQL “stop: Unknown instance:” error – Why it happens and how to fix

by | Oct 16, 2018

Server errors are no fun.

And it is especially frustrating when the error is cryptic, like “Unknown instance“.

What does it mean, really?

A common error people face in VPS, Cloud and Dedicated servers is MySQL failing with “stop: Unknown instance:

# service mysql restart
stop: Unknown instance:
start: Job failed to start

 

What is MySQL “stop: Unknown instance:” error?

When MySQL is restarted, the service scripts will attempt to terminate running MySQL programs, and start the program afresh with the config reloaded.

This goes without a hitch 99.999% of the time, but it is known to fail after server upgrades, migrations or config changes.

When the service script is either unable to kill the existing MySQL processes, or restart the MySQL processes with the new config, the restart will fail with the message:

stop: Unknown instance

Here at Bobcares, we often see this error as part of our Server Management Services for web hosts, digital marketers and other online service providers.

We’ve seen causes as varied as resource bottlenecks to security restrictions for this error.

Here are the top 5 causes for this error, and how we fix them:

 

1. Out of memory

MySQL uses something called global_buffers and thread_buffers to procure memory from the operating system.

When MySQL doesn’t get the requested memory from the system, it fails to start up, causing the restart error.

Solution : We resolve this by optimizing the web and MySQL servers to use lesser memory. We adjust concurrent connection settings, and buffer sizes to reduce the memory footprint, and allow MySQL to start again.

 

2. Permission errors

MySQL needs full read and write permissions to all directories in which it stores data files.

During server migrations or upgrades we’ve seen the permissions and ownership of these folders accidentally change, causing MySQL self-health checks to fail.

Solution : To fix this, we reset the right permissions and ownership (mysql:mysql ownership, 640 permissions for files and 750 for folders) recursively on all MySQL data directories.

 

3. Undead MySQL program

For a MySQL restart to be successful, the existing program should terminate and release all locked files (eg. Socket file, data files, etc.).

During high server load or during resource bottlenecks (eg. disk, memory, net, etc.) the MySQL program won’t exit normally, and this will prevent a proper MySQL restart.

Solution : To solve this, MySQL can be hard killed (using command kill -9), which will forcefully liberate all resources from the process, and terminate it. If that doesn’t fix it, renaming or deleting the MySQL socket file will force the program to quit.

 

4. IP or port binding issues

MySQL will need to listen to an IP address to listen for queries.

We’ve seen firewall updates or server upgrades causing IP and port binding of MySQL to be blocked, thereby causing the MySQL startup to fail.

Solution : There are two ways to fix this:

  • Fix the firewall rules – If it is indeed a firewall rule issue, we track the erring rule down, and change it so as to allow MySQL connections again.
  • Change binding IP – In case the external IP binding is no longer possible, we change the IP to the localhost (aka 127.0.0.1) to allow MySQL start up.

 

5. MySQL config changes

Usually after an upgrade or a migration, we’ve seen MySQL config files to be rest to the default version.

This causes MySQL to not recognize InnoDB databases, look for log files in the wrong folder, and more. Any of this will lead to MySQL startup failure, and thereby cause the restart error.

Solution : We keep a system and config file backup in all servers we maintain. So, in such cases, we restore the MySQL config file so that everything works as before.

 

Security restrictions, file system errors, and more..

MySQL startup errors can be caused by many other issues that includes, AppArmor security restrictions, file system errors like read-only mount, and more.

Here at Bobcares, we find solutions to this in minutes by following the evidence trail left by MySQL programs and log files.

If you need assistance to fix the MySQL error, click here to talk to our MySQL experts. We are online 24/7.

 

Conclusion

MySQL’s “stop: Unknown instance” error can be caused by resource limits, permission errors, security limits and more. Today we discussed the top 5 reasons for this error and how our Support Engineers fix them.

 

PREVENT YOUR SERVER FROM CRASHING!

Never again lose customers to poor server speed! Let us help you.

Our server experts will monitor & maintain your server 24/7 so that it remains lightning fast and secure.

SEE SERVER ADMIN PLANS

var google_conversion_label = "owonCMyG5nEQ0aD71QM";

0 Comments

Submit a Comment

Your email address will not be published. Required fields are marked *

Never again lose customers to poor
server speed! Let us help you.

Privacy Preference Center

Necessary

Necessary cookies help make a website usable by enabling basic functions like page navigation and access to secure areas of the website. The website cannot function properly without these cookies.

PHPSESSID - Preserves user session state across page requests.

gdpr[consent_types] - Used to store user consents.

gdpr[allowed_cookies] - Used to store user allowed cookies.

PHPSESSID, gdpr[consent_types], gdpr[allowed_cookies]
PHPSESSID
WHMCSpKDlPzh2chML

Statistics

Statistic cookies help website owners to understand how visitors interact with websites by collecting and reporting information anonymously.

_ga - Preserves user session state across page requests.

_gat - Used by Google Analytics to throttle request rate

_gid - Registers a unique ID that is used to generate statistical data on how you use the website.

smartlookCookie - Used to collect user device and location information of the site visitors to improve the websites User Experience.

_ga, _gat, _gid
_ga, _gat, _gid
smartlookCookie
_clck, _clsk, CLID, ANONCHK, MR, MUID, SM

Marketing

Marketing cookies are used to track visitors across websites. The intention is to display ads that are relevant and engaging for the individual user and thereby more valuable for publishers and third party advertisers.

IDE - Used by Google DoubleClick to register and report the website user's actions after viewing or clicking one of the advertiser's ads with the purpose of measuring the efficacy of an ad and to present targeted ads to the user.

test_cookie - Used to check if the user's browser supports cookies.

1P_JAR - Google cookie. These cookies are used to collect website statistics and track conversion rates.

NID - Registers a unique ID that identifies a returning user's device. The ID is used for serving ads that are most relevant to the user.

DV - Google ad personalisation

_reb2bgeo - The visitor's geographical location

_reb2bloaded - Whether or not the script loaded for the visitor

_reb2bref - The referring URL for the visit

_reb2bsessionID - The visitor's RB2B session ID

_reb2buid - The visitor's RB2B user ID

IDE, test_cookie, 1P_JAR, NID, DV, NID
IDE, test_cookie
1P_JAR, NID, DV
NID
hblid
_reb2bgeo, _reb2bloaded, _reb2bref, _reb2bsessionID, _reb2buid

Security

These are essential site cookies, used by the google reCAPTCHA. These cookies use an unique identifier to verify if a visitor is human or a bot.

SID, APISID, HSID, NID, PREF
SID, APISID, HSID, NID, PREF