This blog was offline for a while yesterday. One of the perils of shared hosting is that you have to share the mysql database with other people who tend to use up all the available connections etc and an admin has to sort it all out.
The blog was left broken and visitors were advised that the drupal sessions table was corrupted and it needed repairing. How nice of drupal to blab secrets like the name of the database. Repairing the database through the site5 interface didn't work, it didn't even list the sessions table in the results. Fixing it turned out to be quite simple, log into mysql and go:
REPAIR TABLE SESSIONS;
The sessions table had 25,000 entries in it! Since this is old session data and not at all essential (I have the only active account) I zapped it:
DELETE FROM SESSIONS;
Fixed.
Apart from server maintenance, problems with mysql seem to be the main reason for downtime on this blog. Should I move it across to my new server where all the connections are mine and mine alone? If I did I would probably want to make sure I was backing the blog up: I wouldn't want to lose three years and 43 weeks, 1480 articles, a detailed history of my World of Warcraft adventures and the internets primary cuprin0l fence sprayer vitriol page. Site5 do automatic backups, backing up on the new server would be totally down to me. Fortunately I can back it up to... my site5 account!
Twitterings
Peter's Moblog
"DELETE FROM SESSIONS;" will be slow as it will delete all rows individually - MUCH faster to run "TRUNCATE SESSIONS;" when you want to empty all rows out a table, although TRUNCATE will (AFAIK) also reset the auto_increment variable for the table, whereas DELETE FROM will leave it as is... However all Drupal index fields should use the Drupal "way" of indexing as auto_increment is inconsistent between databases I think...