Blog for progress and story developments of my amateur writing.
Planning to have some original content posted as well!
Friday, June 22, 2007
Site down
The site is down. Larry F says that it's a problem with the server and the hosting company should have it fixed soon.
11 comments:
Anonymous
said...
If any of the staff has access to phpMyAdmin (or it can be done via SQL from command-line or a PHP script), you should be able to fix the problem yourself in seconds.
The problem: The MySQL server crashed while at least one table was being written to. Because MySQL only supports one write action at a time, the table is locked for every such action, and it wasn't unlocked because the server crashed in the meantime. Hence, MySQL refuses to access the table for anything other than a repair.
The solution: Do the repair. phpMyAdmin will list all locked tables as "in use" in the table list - you can check them and select the "Repair Table" option to unlock them. Alternatively, run the command "REPAIR TABLE table_name" directly. It usually takes between 1 and 30 seconds depending on the size of the table, but the result is almost always an undamaged table.
I hope the site will be up and running again soon. It seemed to go down sometime arround 2:15 or 2:30 my time and I'm making this comment close to 11 my time.
It's a little odd that this error that took down the site happened almost exactly half an hour after I last saw Stacy online.
Hope it's an easy fix and the site is back up to normal tomarrow.
I'd assume FF already has backups of the database(s).
As it is now the "repair table" fix won't work, as the server's not accepting the forum's authentication for whatever reason. May be something still problematic on the host's end (which is strange as it's been well over 12 hours and repair of important services is a priority).
B'man your first fix has been tried and it did change things, looks like what's the remaining problem is host side, as you said. As more information comes in I'll post
"Repair table" would've had to have been performed at some point, by either FFs or the host, so that's fine. What's up now is surely a separate problem, as the forum wouldn't try to access a table (as it was doing yesterday) if it couldn't log in at all (which is the case now).
The possibility that springs to mind is that the database logins have been lost as a result of the upgrade or whatever they were doing. A well-handled MySQL upgrade won't lose any data and involves less than a minute of downtime, so the actual cause is probably more complex.
Any solution, such as granting access to the forum's DB username again, might get in the way of the hosts' work, so I won't suggest it ;p
One unlikely possibility that caught me out similarly a couple of years ago, is that older versions of cPanel (so ignore this whole paragraph if your host doesn't use it ;p) allow the root user for your account (if your DBs start with "fukufics_" then the root is "fukufics") to have full access to all the DBs. Older versions don't, and require you to grant permissions yourself. Something to look at, if you've had a recent cP upgrade...
Anyway, to be honest I'd just let the host do their thing (assuming they are doing something >_>). Good luck whoever's doing the work, and I'm looking forward to seeing FFs back again.
Correction in the last post: Older versions don't, and require you to grant permissions yourself. to Newer versions don't, and require you to grant permissions yourself.
My question is this... If there was a "update" to sql, php or cP, then wouldn't there be a backup of the original settings that by either resetting the calander date to the time before the act of updating, or logging into the "older" files to at least allow the admins in to figure out what "broke" the system and correct it? just a thought
The error message says that a userid that phpBB is using to read a MySQL 4 database no longer exists or has had its password changed.
Depending on the host, either the host or the client is responsible for the various usernames and access levels of MySQL databases. Restoring the username is one line job, but its a matter of *who* is responsible for it. On my host, it's my responsibility to manage usernames.
The other two error messages look like side effects of not having a proper username/password combination on MySQL.
11 comments:
If any of the staff has access to phpMyAdmin (or it can be done via SQL from command-line or a PHP script), you should be able to fix the problem yourself in seconds.
The problem: The MySQL server crashed while at least one table was being written to. Because MySQL only supports one write action at a time, the table is locked for every such action, and it wasn't unlocked because the server crashed in the meantime. Hence, MySQL refuses to access the table for anything other than a repair.
The solution: Do the repair. phpMyAdmin will list all locked tables as "in use" in the table list - you can check them and select the "Repair Table" option to unlock them. Alternatively, run the command "REPAIR TABLE table_name" directly. It usually takes between 1 and 30 seconds depending on the size of the table, but the result is almost always an undamaged table.
I hope the site will be up and running again soon. It seemed to go down sometime arround 2:15 or 2:30 my time and I'm making this comment close to 11 my time.
It's a little odd that this error that took down the site happened almost exactly half an hour after I last saw Stacy online.
Hope it's an easy fix and the site is back up to normal tomarrow.
I was already wondering if the new mayhem in Spamville now decided to have more drastic repercussions all over the forum :P
Oh well... Just have to wait it out I guess :D
I think b'man is right, but I'd advise dumping (not dropping) the database as a backup before and after the repair.
I'd assume FF already has backups of the database(s).
As it is now the "repair table" fix won't work, as the server's not accepting the forum's authentication for whatever reason. May be something still problematic on the host's end (which is strange as it's been well over 12 hours and repair of important services is a priority).
B'man your first fix has been tried and it did change things, looks like what's the remaining problem is host side, as you said. As more information comes in I'll post
Yesterday it was a PHP table error, today it's a few SQL errors. It makes me wonder if the host tried to fix the problem by upgrading SQL on the site.
Maybe another error was seen earlier today but right now I'm seeing errors in /home/fukufics/www/db/mysql4.php
lines 48, 330 and 331
I really hope this isn't being too much of a headache to whomever is working on it. My guess being Stacy.
"Repair table" would've had to have been performed at some point, by either FFs or the host, so that's fine. What's up now is surely a separate problem, as the forum wouldn't try to access a table (as it was doing yesterday) if it couldn't log in at all (which is the case now).
The possibility that springs to mind is that the database logins have been lost as a result of the upgrade or whatever they were doing. A well-handled MySQL upgrade won't lose any data and involves less than a minute of downtime, so the actual cause is probably more complex.
Any solution, such as granting access to the forum's DB username again, might get in the way of the hosts' work, so I won't suggest it ;p
One unlikely possibility that caught me out similarly a couple of years ago, is that older versions of cPanel (so ignore this whole paragraph if your host doesn't use it ;p) allow the root user for your account (if your DBs start with "fukufics_" then the root is "fukufics") to have full access to all the DBs. Older versions don't, and require you to grant permissions yourself. Something to look at, if you've had a recent cP upgrade...
Anyway, to be honest I'd just let the host do their thing (assuming they are doing something >_>). Good luck whoever's doing the work, and I'm looking forward to seeing FFs back again.
They say absence makes the heart grow fonder...
Correction in the last post:
Older versions don't, and require you to grant permissions yourself.
to
Newer versions don't, and require you to grant permissions yourself.
My question is this... If there was a "update" to sql, php or cP, then wouldn't there be a backup of the original settings that by either resetting the calander date to the time before the act of updating, or logging into the "older" files to at least allow the admins in to figure out what "broke" the system and correct it? just a thought
Talonhunter:
Assuming they've taken one.
The error message says that a userid that phpBB is using to read a MySQL 4 database no longer exists or has had its password changed.
Depending on the host, either the host or the client is responsible for the various usernames and access levels of MySQL databases. Restoring the username is one line job, but its a matter of *who* is responsible for it. On my host, it's my responsibility to manage usernames.
The other two error messages look like side effects of not having a proper username/password combination on MySQL.
Post a Comment