maria-discuss team mailing list archive

[Reindl Harald <h.reindl@xxxxxxxxxxxxx>]

Hi

Am 27.10.2013 14:12, schrieb Michael Widenius:
>>>>>> "Reindl" == Reindl Harald <h.reindl@xxxxxxxxxxxxx> 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!

Attachment: signature.asc
Description: OpenPGP digital signature