I did "CHECK TABLE mytable" and there were two rows with Msg_text:
"Table is marked as crashed"
"OK"
I took about 10 mins to review how 'myisamchk' works, then ran CHECK TABLE again to verify the error, but to my surprise the error was no longer there.
I reviewed CHECK TABLE documentation and see sentence ..
"For MyISAM tables, the key statistics are updated as well."
The table is "MyISAM".
Is it possible that ...
- the NON-updated stats were causing the "...crashed" error
- and that updating those stats via CHECK TABLE resolved the error?
Thanks
It works something like this...
While mysqld is running, it has a flag set in any index (.MYI file) that it is using. Normally index updates are written to the .MYI file, but with no sense of urgency, since they are cached in the "key_buffer".
When mysqld terminates un-gracefully (eg, because of a power failure), mysqld has no chance to clear the flag. After restarting, mysqld sees the flag and says "oh, panic; this index may be corrupted". Then, you have to come in and take action to clear the flag and, if necessary, fix the corruption using REPAIR TABLE or the equivalent myisamchk with suitable arguments.
Often, the index is not really corrupt, and the CHECK/REPAIR is not really needed. But MySQL can't be sure. Hence, the somewhat alarming message.
It is possible to have a setting so that MyISAM tables will be checked and repaired during startup. I rarely see myisam_recover_options set to anything other than OFF.
If you switch to InnoDB, you can mostly forget about all this stuff.
Related
I have a MySQL table named requests. It's growing so fast. Currently, it has 3 million rows. Also, the current table engine is "InnoDB".
Few days ago, I got this error:
ERROR 1114 (HY000): The table is full
I've resolved the problem (temporary I guess) by adding this to MySQL configuration:
innodb_data_file_path = ibdata1:10M:autoextend
But still sometimes my serves goes to down and I have to restart it to make it available. Recently, I've made that table empty and I got rid of being down.
But it will be full again soon. Any idea how can I fix that issue? Should I use another engine for that table? Should I use compressed type-row for it? or what?
Noted that, sometimes I need to select from that table and it has one index on a column (in addition to pk)
You are limited by disk space. You must keep an eye on that and take action before you get to "table full".
If you store the data in a MyISAM table, you can go twice as long before getting "table full". If you simply write to a disk file (no database, no queries; etc), you can squeeze a little more in before "disk full".
Do you need to "purge" old data? That way you could continue to receive new data without ever hitting "table full". The best way to do that is via InnoDB and PARTITION BY RANGE(TO_DAYS(...)). If you purge anything over a month old, use daily partitions. For, say, 90 days, use weekly partitions. More discussion: http://mysql.rjweb.org/doc.php/partitionmaint
What will you do with the data? Analyze it? Search it? What SQL queries do you envision? Answer those; there could be other tips.
everyone! I'm trying to avoid breaking of my database in the phpbb3.1 forum. It was crushed twice this month.
So I have two questions:
1) Is it safe to convert MyISAM to InnoDB? I mean will extensions work fine? Will forum be workable after updating to next version?
2) In which way I can avoid base corrupting?
p.s.
I also posted this question here:
https://www.phpbb.com/community/viewtopic.php?f=466&t=2436326
I'll venture a guess. You had a power failure, and when it came back up, MySQL was complaining that some index on some table was corrupted? And that table was MyISAM?
Use myisamchk to repair the tables.
Review the gotchas in http://mysql.rjweb.org/doc.php/myisam2innodb to see if conversion to InnoDB will add new woes. There probably won't be any. A 2-part PRIMARY KEY is about the only thing that is not implemented in InnoDB. Also, if you have too old a version of MySQL, InnoDB may not yet have FULLTEXT indexes (if you need them).
Change my.cnf: key_buffer_size = 20M and innodb_buffer_pool_size equal to about half of available memory.
ALTER TABLE xx ENGINE=InnoDB; for each table xx.
I think (but am not sure) that each update/delete/insert marks the table as possibly corrupt. It writes the changes, but does not clear the mark. When mysqld shuts down cleanly, everything is flushed to disk and these flags are cleared. When mysqld comes back up, it complains about the flags that did not get cleared. So...
Whether or not an index is marked as corrupt depends solely on whether you modified that index and crashed. (Every table has some index, yes?)
Normally, MySQL manages to flush changes to disk before a crash. Only occasionally does the crash happen at a time where the index will really be corrupt. There is a "quick" mode on the repair that simply clears the flag -- you could try that. But if you ever get a mysterious "can't find record" when you know the records exists, you'd better REPAIR it.
Sometimes tables in the mySQL database crash after a server restart or after a lost connection to the database.
This have happen several times for the last 3-4 weeks.
This is how the error message looks like:
145 - Table './xxx/sessions' is marked as crashed and should be
repaired select value from sessions where sesskey =
'60fa1fab3a3d285cfb7bc1c93bb85f64' and expiry > '1395226673'
[TEP STOP]
So far it’s have been the tables "sessions" and "whos_online" that have crashed. If I repair the tables in phpmyadmin it will work fine again
After the last crash I changed "sessions" from MyISAM to InnoDB. The table "whos_online" still use MyISAM.
I use osCommerce 2.2 rc2a and I'm looking for any thoughts and suggestions in this matter.
One solution might be to change both these tables to InnoDB, since it supposed to be self-healing. Is that a good or bad idea?
Another one would be to have them in MyISAM and do something like this with the php-file that echo the error message:
if $error contain "is marked as crashed and should be repaired"
run a table repair script
Would that be a good or bad idea?
Here’s my server specs
Database: MySQL 5.5.36-cll
PHP Version: 5.3.15
At first you should address the issue that tables become corrupted in the first place. InnoDB tries to repair broken files, but it cannot do magic. Repeated unsafe shutdowns or other accidents may seriously corrupt your database!
If you only have a small website, all variants are good. MyISAM is a little faster (sometimes), while InnoDB provides some extended features. If the server is strong enough, you will likely encounter no issues. I would stick with InnoDB in most cases as it accounts for consistent data and throws errors if files are broken, unlike MYISAM tables which are used and then sometimes throw errors in production...
But if something severely breaks, it requires more effort to get MySQL with InnoDB back up running if it does not automatically. There exist different InnoDB recovery modes which are only available from the shell of your server and require modifying the config file, starting the server by hand, reading its output and maybe doing some other actions. If you do not have any clue of these issues, you might want to stick with MyISAM instead. The server always starts, and if the table is utterly broken, you might need to import a backup. But this is more easily than editing config files and reading database outputs etc.
Apologize but I really don't have much information for the question.
I have a single MySQL MySIAM engine table that's holding around 80K records (continually increase).
Today it's suddenly stop responding.
I can't even do a single query (e.g. SELECT * FROM table LIMIT 1), the server just spend time executing and look like will never stop.
I can't dump table to make backup.
However, another tables in the same database, same engine (MySIAM) are working just fine.
I'm not sure where to go from here. Not sure if it's DEADLOCK or anything.
All data in that table is really important. You direction pointing to help me identify the problem would be really appreciated. For example, are there any command to check table if it's corrupt by what reasons, etc.
UPDATE:::::
I can't use CHECK TABLE neither, it also take forever execution time.
UPDATE ::::
I did research and come up with something about REPAIR TABLE.
However, it's suggested that I should do the backup first.
As I can't do the back for this table, would it be OK to use the REPAIR command anyway?
::::::::::::: SOLVED :::::::::::
Follow Cristian's help, use SHOW PROCESSLIST; command. I see that there is a process with state 'Copying to tmp table' that hold another process.
So I use KILL <process id> to kill that process and everything released to normal.
Cheers
Chanon
Sorry but I can't comment your question... :)
Exactly which version of MySQL you run, 5.1.xx?
Can you post you SHOW PROCESSLIST; status?
UPDATE: Chanon, after this event, and to prevent this problem, you have to review and optimize the query that send MySQL in "Copying to tmp table" state, in order to avoid slowness and a risk of "disk full" for your temporary partition.
sometimes i get an error like "table is marked as corrupt and shld be repaired". that DB (tables) is using MyISAM. recently that keeps happening. what could be the causes? most recently i am executing a batch insert
INSERT INTO table (..., ..., ...) VALUES (...), (...), (...) ...
and it just hung. or took very long to complete it seems hung to me. the next day, when i checked the table was marked as corrupt again. when i try to use mysqlcheck -r it said all tables OK when it reached that "corrupt" table it hung there again...
so, what can i do to prevent this. and what could be the causes. the DB is hosted 3rd party, how can i debug this?
is InnoDB a more reliable engine to use? i heard MyISAM is faster but others say InnoDB can be fast also but it takes abit more to optimize it. can i conclude that InnoDB is something more reliable but abit slower overall even with optimization?
If your tables get corrupt, you can use the repair table command to fix them:
REPAIR TABLE table;
If you run myisamchk while the server is still running (and inserts/selects are hitting the table), it could be what is corrupting your tables. Most of the corruption issues I run into are when trying to do things outside the server (copying the files, etc) while it is still running.
InnoDB is slower for read only databases, because it has features (ACID compliant, row level locking) that MyISAM leaves out. However, if you are doing a mixture of reads and writes, depending on the mixture, then InnoDB can offer serious performance improvements, because it doesn't have to lock the entire table to do a write. You also don't run into corruption issues.
Go with InnoDB.
ok, so the problem was the company's db exceeded the storage space allowed by the hosting company. so apparently noone told the company they exceeded the usage ... lousy host i guess.
btw, theres no way mysql could have known abt this?