We have a website that has a table of tax rates that somehow got corrupted one day.
I tried selecting * from theTable but it literally took hours to yield nothing.
I tried truncating and dropping the table. Produced the same results as the select.
Eventually the actions stopped. So, I ran a
myisamchk -r theTable.MYI
Repaired looks like it went okay, but I tried selecting * from it again and still producing the same results.
Engine is MySQL
It would be easy to reproduce the table, can I just delete theTable.* (frm, MYD, MYI)?
Or if there is a better approach to what I'm doing.
Yes, you can delete the .FRM, .MYD, .MYI files to remove a MyISAM table. This is what happens when you DROP TABLE.
MyISAM tables are infamous for getting corrupted. But the fact that you got repeated problems after recreating the table makes me wonder if you have a failing hard drive. It would be worth testing the health of your hard drive.
You should also switch to use InnoDB instead of MyISAM. InnoDB has a lot of protections against corruption, including page checksums, synchronous disk writes, crash recovery, etc. MyISAM is being slowly phased out and is receiving no fixes from MySQL developers. InnoDB is now the default storage engine as of MySQL 5.5 (circa 2010), and it will continue to be the focus of future development.
Note that with InnoDB, you cannot simply delete files to achieve dropping a table like you could with MyISAM. You must use DROP TABLE so InnoDB synchronizes that drop with its internal data dictionary.
Related
My client has a store on Woocommerce with 1.2 Gb database. I know that similar store (count by product ) should have approx 700Mb.
The biggest table is wp_posts (760Mb) alone ! Which, I think is strange. Usually biggest table is wp_postmete or wp_options.
I tried optimize this database by plugins: WP-Sweep and wp-optimize so there is no revisions and draft left.
I also tried SQL:
OPTIMIZE TABLE
but it is innoDB so it do not support it. I get this message:
Table does not support optimize,doing recreate + analyze instead
So it is done? I mean:”recreate + analyze” or I should do it? And how?
I read that in innoDB i should dump table and restore but when I do this by DBeaver - i get same size.
Any Idea what should I do?
The error message is a bit misleading, because it dates back to the days when MyISAM was the default storage engine, and OPTIMIZE TABLE does a few things in MyISAM that are different from what it does in InnoDB. For example, MyISAM can't reclaim space from deleted rows until you do OPTIMIZE TABLE (whereas InnoDB does reclaim space dynamically).
InnoDB does support OPTIMIZE TABLE and it does useful things. It does basically the same as an ALTER TABLE when using the COPY algorithm. That is, it creates a new file, and copies the data row by row into the new file. This accomplishes defragmentation and rebuilding the indexes, just as if you had done a dump and restore. So you don't need to dump and restore.
After OPTIMIZE TABLE, the InnoDB table may be close to the same size it was before, if there was little fragmentation.
Frankly, a table 1.2GB in size is not so large by the standards of most MySQL projects I've worked on. We start to get concerned if a table is larger than 500GB, and we start alerting developers if the table is larger than 800GB, or larger than the remaining free disk space.
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.
I have a myISAM table with 2.5 million and rising rows. It is myisam as I require FullText searching.
Having done some research on stackoverflow I'm looking into creating the table again as a InnoDB table and then creating a copy in myISAM. Then I will create triggers which will replicate any changes in the innodb table to the myisam table.
The innodb table will function better as it works transactionally and doesn't lock the whole table when it is written to or updated.
My question is: Will I see much benefit in the myisam table as surely it is going to be written to as often as before because every write to the innodb table will result in a subsequent write to the myisam.
Any suggestions, or other ideas gratefully received.
Brett
Using triggers to copy from MyISAM to InnoDB has the risk of creating inconsistent data, when transactions are rolled back.
A better idea might be to install a full text search engine like Sphinx that can work with InnoDB tables.
Another idea would be to synchronise MyISAM with InnoDB periodically using event scheduler. You risk that full text search would return stale data, but on the other hand this should have less of an impact on performance, and at least you know data is consistent after each sync.
Also some good news: starting with MySQL 5.6 InnoDB gets full text searches.
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?