Every so often I get an error saying one of my tables "is marked as crashed and should be repaired". I then do a REPAIR TABLE and repair it. What causes them to be marked as crashed and how can I prevent it? I am using MyISAM tables with MySQL 5.0.45.
There can be a few reasons tables get corrupted, it is discussed in detail in the manual.
To combat it, the following things work best:
Make sure you always MySQL shutdown properly
Consider using --myisam-recover option to automatically check/repair your tables in the event that shutdown wasn't done properly
Make sure you are on the most recent versions as known corruption bugs are normally fixed ASAP
Double check your hardware with a test to see if it is causing problems. Tools like sysbench and memtest86 can often help verify if things are working as they should.
Make sure nothing is touching the data directory externally, such as virus checkers, backup programs, etc...
Usually, it happens when the database is not shut down properly, like a system crash, or hardware problem.
I used to get errors from mysql just like you.
I solved my problems in this way
Convert to all myisam tables to InnoDB (you can search "myisam vs InnoDB" in stackoverflow.com and search engines to find out why)
For getting best performance from MySQL, use a third-party program MONyog
(MySQL Monitor and Advisor) and check performance tips
These two steps saved me. I hope these also help you lot.
It could be many things, but MySQL Performance Blog mentions bad memory, OS or MySQL bugs that could cause hidden corruption. Also, that and another article mention several things to keep in mind when doing crash recovery.
Related
MySQL was shut down in the middle of an indexing operation.
It still works but some of the queries seem much slower than before.
Is there anything particular we can check?
Is it possible that an index gets half way through?
Thanks much
As a suggested in my comment, you could try a repair on the relevant table(s).
That said, there's a section of the MySQL manual dedicated to this precise topic, which details how to use the REPAIR <table> statement and indeed dump/re-import.
Is this doesn't make any difference, you may need to check the database settings (if it's a InnoDB engined table/database, it'll love being able to be resident in memory for example) and perhaps try to see what specific indexes are being used via an EXPLAIN on the queries that are causing pain.
There are also commercial tools such as New Relic that'll show what specific queries are being sluggish in quite a lot of detail as well as monitoring other aspects of your system, which may be worth exploring if this is a commercial project/web site.
I'm adding modules to a Drupal site and am getting dreaded fatal memory errors. I went to clear the accesslog, cache, and watchdog tables, but am still getting such errors. I'm only running one database on this site and it's for Drupal use, but I am wondering what other tables I can free up. I'm sure some of the myriad tables listed in phpMyAdmin are more critical to Drupal than others. Can I blindly clear all tables with "Overhead" or would that be a major faux pas?
Any insight would be most excellent.
No, you can not simply clear some tables. It also doesn't help at all with out of memory errors anyway.
There are really only two ways to fight out of memory errors. a) Increase the memory limit, 64MB should be the minimum, with many modules, it might even need more. and b) disable some modules.
To add to Berdir's answer, a c) would be to profile memory usage and figure out what's eating memory, and if there's a way to optimize or cache it's output.
Install devel and turn on performance logging, it'll tell you what queries and modules are eating up the most memory. You can also use xdebug and a cachegrind utility to diagnose this in-depth, but it'll take a while to set up.
If you truncate database tables, the problem will just come back when more stuff fills up those tables.
Best thing to do is just to increase your PHP memory limit, though.
I have a database that is read-only in nature. So it seems to make sense to boost performance by setting it to readonly. Then I get updates for this database once a month. At that point I would like to switch to readwrite, do the updates, and switch back to readonly. I've looked around and haven't seen too much mention of this. Are there any problems I'm going to run into with this approach or is this as safe and basic as you get?
thanks
No problems with this approach.
Remember to rebuild index and update stats before making it read only again.
Then again, keep it simple and read write always...?
Out of blue moon, all of sudden, 1 of my database is crashed. This is not the first time, last time I use the "repair table" command and was lucky able to fix it. But it happens again, same table, same error, same solution.
Error:
1194: Table 'users' is marked as crashed and should be repaired
Do I need to repair my tables every day/week/month? Is there a permanent solution for "table-crashing" problem? Its really scary!!! Please help
This shouldn't happen normally, if your tables are crashing it means something is wrong with your system. Likely a bad disk or bad DRAM (or one of lots of unlikely things, like bad pci->sata bridge, etc...). If you have another system around, try migrating to that system and see if your errors continue.
You do have another equivalent system around, right? In case the primary DB crashes hard, and you need to restore a backup ASAP?
I suppose it could also be a bug in mysql, make sure the version you are using doesn't have known bugs.
To debug this problem, let alone just about any other problem, start looking in your logs. If you MySQL server runs on Windows, there are event logs for application and system, and I would look at those. If your MySQL server runs on Linux, logs are usually found under /var/log, and you usually have to be root to view them. A good way to view on linux is
tail (where is replaced by the real name of the file).
As you have been advised in another answer, you might have disk issues. Run a hardware diagnostic on the disks.
Whatever you decide to do, please do not depend on repairing a table; because you soon might not be able to. Using an Informix SE database, I had to rebuild a table, and there was nothing apparently wrong with the data in the table. It was a nightmare, and took the better part of a weekend. I could not export the database, on which our test and development systems depend.
I've had a tough time setting up my replication server. Is there any program (OS X, Windows, Linux, or PHP no problem) that lets me monitor and resolve replication issues? (btw, for those following, I've been on this issue here, here, here and here)
My production database is several megs in size and growing. Every time the database replication stops and the databases inevitably begin to slide out of sync i cringe. My last resync from dump took almost 4 hours roundtrip!
As always, even after sync, I run into this kind of show-stopping error:
Error 'Duplicate entry '252440' for key 1' on query.
I would love it if there was some way to closely monitor whats going on and perhaps let the software deal with it. I'm even all ears for service companies which may help me monitor my data better. Or an alternate way to mirror altogether.
Edit: going through my previous questions i found this which helps tremendously. I'm still all ears on the monitoring solution.
To monitor the servers we use the free tools from Maatkit ... simple, yet efficient.
The binary replication is available in 5.1, so I guess you've got some balls. We still use 5.0 and it works OK, but of course we had our share of issues with it.
We use a Master-Master replication with a MySql Proxy as a load-balancer in front, and to prevent it from having errors:
we removed all unique indexes
for the few cases where we really needed unique constraints we made sure we used REPLACE instead of INSERT (MySql Proxy can be used to guard for proper usage ... it can even rewrite your queries)
scheduled scripts doing intensive reports are always accessing the same server (not the load-balancer) ... so that dangerous operations are replicated safely
Yeah, I know it sounds simple and stupid, but it solved 95% of all the problems we had.
We use mysql replication to replicate data to close to 30 servers. We monitor them with nagios. You can probably check the replication status and use an event handler to restart it with 'SET GLOBAL SQL_SLAVE_SKIP_COUNTER=1; Start Slave;'. That will fix the error, but you'll lose the insert that caused the error.
About the error, do you use memory tables on your slaves? I ask this because the only time we ever got a lot of these error they where caused by a bug in the latests releases of mysql. 'Delete From Table Where Field = Value' will delete only one row in memory tables even though they where multiple rows.
mysql bug descritpion