Accesslog is marked as crashed and should be repaired

What happens if you "check" the table?

I have the same exact problem in 2 of my Drupal installations. One is a 5.x series and the other is a 6.4 install. Both tell me:

user warning: Table './wachs-drupal/accesslog' is marked as crashed and should be repaired query: INSERT INTO accesslog (title, path, url, hostname, uid, sid, timer, timestamp) values('Firefighting', 'aggregator/categories/4', 'http://www.xxx.org/aggregator/categories/4', '70.167.108.25', 1, 'b5b81e8693d0ec1b3b36ec957deede46', 281, 1220054064) in /Volumes/web/clients/xxx-org/modules/statistics/statistics.module on line 64.

I've checked statistics.module and it contains the correct info. I've re-installed Drupal. I've re-started MySQL and the server. Problem persists on both installs.

Can you confirm if you have run the MySQL check/repair options on the accesslog table and/or the entire database in each case?

I have run check on it. Here are the errors:

scooternews-drupal.watchdog
warning : Table is marked as crashed
warning : 1 client is using or hasn't closed the table properly
error : Record at pos: 1558260 is not remove-marked
error : record delete-link-chain corrupted
error : Corrupt

Repair on that database only fixed it after I removed the table "accesslog" and rebuilt it by hand.

Looks like there were problems in watchdog table also, glad you've got it working now. Given this appears to be a MySQL problem ("repair" should work, after all) maybe try upgrading that? Or reducing server load.

Marking as fixed for now.

In case this info is of use:

The accesslog table records accesses to the site (obvious, I know...). This data was not critical for my site, and the error appearing on all pages was a problem. Just replacing the bad table with a good one worked fine.

Delete the bad accesslog and get hold of a good table (just use one (copy structure only) from your most recent backup).

If your site is on a hosted server and you don't have privileges for tweaking mysql, this workaround might help.

(The error appears to have coincided with a cron job error at my site.)

This post helped me solve my problem. By checking the watchdog table I was able to see the messages listing bad indexes on 7 total tables:

Incorrect key file for table './meco_stweeps/filter_formats.MYI'; try to repair it query: SELECT cache FROM filter_formats WHERE format = 3 in /usr/www/users/meco/stws/modules/filter/filter.module on line 366.

the command in mysql is as simple as "REPAIR TABLE filter_formats;" done for each table showing errors in watchdog. You can see the errors in the tables before repairing them using "CHECK TABLE filter_formats;"

Here's a sample:
| meco_stweeps.filter_formats | check | warning | Size of indexfile is: 23199 Should be: 4096 |
-> | meco_stweeps.filter_formats | check | error | Can't read indexpage from filepos: 1024 |
'> | meco_stweeps.filter_formats | check | Error | Incorrect key file for table './meco_stweeps/filter_formats.MYI'; try to repair it |
'> | meco_stweeps.filter_formats | check | error | Corrupt

Once I issued the repair command on each corrupt table my entire site and all its data was restored. I didn't lose a thing from what looked like a devastating db failure.

I did have trouble in this case with all my views vanishing site wide, any menu item or block display that used a view did not appear until I accessed the views module, opened one single view and then saved it. This must have rebuilt some internal indexing because at that point all of my missing views appeared, and all the menu items linking to them. Since my homepage content uses a view the repair did not appear to have fixed the site until I performed this step, but at which point everything now seems ship shape.

Just want to thank those above for posting their own expert solutions! Definitely saved me this morning. Thanks so much!

I thought others in the future who, like myself, have less MySQL experience than exhibited by those posting here above might assume, might find useful a "See Dick Run" version of how to fix this problem.

1. Bring up "MySQL Administrator" program (my version is 1.2.12)
2. from the "Views" drop-down menu at the top of the page (or the default left-hand sidebar), click on "Catalog".
3. click on the error-identified table name (e.g., "accesslog" -- which the MySQL Administrator already highlighted in red)
4. click on the bottom "Maintenance" button
5. on the popped-up window, click on "Repair Tables"
6. check "Quick"
7. click on the "Repair Tables" button

And, at least for me, this fixed it (without deleting any data from accesslog, as far as I can currently tell). Thanks again for all those who provided excellent information and examples above. I'm indebted.

You can also simply run

sudo mysqlcheck [databasename] -p

on the commandline if you have telnet/ssh access

When I do this, I find that it's not just accesslog that gives me the dreaded "client is using or hasn't closed the table properly".. It's comments, counters, tracker... well anything that counts stuff.

(note: only sudo if your user isn't allowed access to database)