Hi Am 27.10.2013 14:12, schrieb Michael Widenius:
"Reindl" == Reindl Harald <h.reindl@thelounge.net> writes:
<cut>
131023 11:30:02 [ERROR] mysqld: Table './hvb/andersentag_meta' is marked as crashed and should be repaired 131023 11:30:02 [Warning] Checking table: './hvb/andersentag_meta' 131023 11:30:02 [ERROR] hvb.andersentag_meta: 1 client is using or hasn't closed the table properly
Reindl> Am 23.10.2013 17:38, schrieb Jocelyn Fournier:
I suspect the DELAY_KEY_WRITE to be guilty in your case, are all the crashed table created with DELAY_KEY_WRITE=1 ?
Reindl> yes they are because *any* tables are created this way for years Reindl> also in production for around 10000 tables and that is why this Reindl> scares me to replace MySQL with MariaDB for now
I don't know of any issue with DELAY_KEY_WRITE that could cause this issue. What DELAY_KEY_WRITE could cause is that if your server is going down hard, a repair would be needed to reconstruct the index.
the sevrer for sure did not go hard down
The reasons one can get this error are: - mysqld was killed while some MyISAM that was modified was opened. - One copied an MyISAM table while it was modified. - One copied an MyISAM file that was not closed properly.
To find out what is wrong, it would be good to once and for all that all your tables are ok.
You can do it the following way on the slave:
Stop the slave. run myisamchk --check --fast --force data-directory/*/*.MYI
After the above, you can know for sure that all your tables are properly marked as closed. The --force option will do a check and repair of any table that was not correct.
If you get any new errors that the table was not closed properly and there has not been any restart of mysqld then we know that there is some bug in the mysqld that doesn't properly decrement the table on close.
i did this a few days ago and no error anymore, however, i expected myisam-recover-options = "FORCE" doing the same, but also possible that it did and the changing tables is because my cms-cleanups chossing some random installations each day to spread the load and not invalidate too much query caches it's hard to recover the history, AFAIk there where a crash of mysqld i can't explain and only guess 5 MB innodb_buffer_pool was too small for heavy dbmail-cleanup which are replicated too and the MyISAM messages where a possible result days later
I am not aware of any such bugs and the open/close code has not been touched in a very long time. But of course anything is possible. If this is the case we would like to find a way to repeat your issue so that we can fix this ASAP
that was my intention on the at least second day with such messages
Regards, Monty
Thank you so muich for Feedback harry!