Hi Am 27.10.2013 14:12, schrieb Michael Widenius: >>>>>> "Reindl" == Reindl Harald <[email protected]> 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!
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Mailing list: https://launchpad.net/~maria-discuss Post to : [email protected] Unsubscribe : https://launchpad.net/~maria-discuss More help : https://help.launchpad.net/ListHelp
