> > One of my coworkers insists that this is due to corrupt indexes, stating
> > that if an index points to a location outside of the record set
> mysql gets
> > confused and hangs.
> Does he have any evidence whatsoever for that? I'm 99% sure he's
> wrong--at least in *our* cases. :-)
A crash was recreated by running a specific query. When myisamchk ran upon
restart it said the index file for the table that was being queried was
corrupt. After careful observation, it was discovered that this is often
the case, indexes for tables mentioned in the update log right before a
crash were corrupt upon restart. I'm more inclined to believe that they are
corrupt due to us killing mysqld with the tables still open, since we can't
authenticate to shutdown. We also get a lot of table handler errors from
myisamchk after a crash and kill, go figure.
> We've seen that happen too on more recent FreeBSD versions with
> LinuxThreads. So far it's not happening all that often and it seems
> that the chance of it happening is much greater right after MySQL has
> been [re]started.
> I haven't had much luck in tracking it down further. But I have a few
> more ideas next time I see it.
We aren't running Linux threads. We didn't seem to be experiencing any of
the issues it helps. For a while we'd only have this happen once a month,
then it was once a week. Lately it has been a few times a day, but everyone
is messing with box. In my opinion, for us it definitely happens when an
expensive query is run on an active table. Looking at the logs, there's
always a bunch of disconnects all at once right before connections stop.
I've been on the box at the mysql prompt quite a few times when it has
happened and there was always a large amount of threads waiting for a lock
to clear, and as soon as they went through nothing could connect, but this
doesn't happen everytime we have a large queue, so there must be something
else in the mix. If you think any info I have might help you, let me know.
I'd love to hear any ideas you have.