I was at my office workstation looking at web1 when suddenly my site…and every other site on web 1..vanished. All i started seeing was MySQL database connection errors. The amount of errors escalated until MySQL crashed completely. Attempts to restart MySQL failed…it simply refused to startup. I went through the logs and could not find a reason why it first crashed and then now refused to start at all. I went hosting account by hosting account…trying to figure out what was going on. I then found something odd. One account had not only hit its disk quota..but it was more than 20 percent over. Apparently so much stuff got uploaded so quickly the quota check system didn’t catch it in time. Once it did, the quota system put a hard write lock on all account files..including the sql database file…but only for the account over quota…not all databases. Why MySQL freaked out by crashing the entire database server is one myself and my control panel company are trying to figure out. It gets more fun. i deleted the account in question…which then allowed MySQL to fire back up. One problem fixed…but now I have another one.
I have spent the past 4 days chasing a ghost. The ghost was a database that actually no longer existed…but MySQL was insistent it was still there. This cause MySQL it not allow the site to be restored because it thought the database was already there and refused to allow the restore. So when i tried to re-delete the database i got the following error:
Failed to drop databases : SQL select count(*) from
wp_commentmeta failed : Tablespace is missing for table
I spent days trying to figure out where this ghost database was hiding. i spent days inside the root shell of MySQL itself trying to figure out how to excise this ghost database. It would show up in the list..but the files and pointers got deleted when i deleted the account. i finally tried the “drop database” command from the MySQL root shell and got the same error. some more research showed another command, “drop database if exists”…that nuked it successfully. At least now I know how to address this issue if it shows up again. I’ll be filing a bug report with virtualmin so they can add a sanity check or something to see if this can be prevented from occurring in the future…both for disk quotas and subsequent database deletions..:)