All your database are belong to discourse

end

Replied

Thanks for letting us know. For some reason mysqld keeps crashing - seemingly at random. Luckily enough this is not affecting our operational hosting service, just the website.

I'm going to put service mysql restart in cron or so :) Or get rid of InnoDB..

Everything going well at your side? Discourse is definitely getting more mature and complete, and incredibly stable. Good job!

Apologies for last para, you may want to close your eyes through that section.

PJH

@codinghorror said:

I'm going to put service mysql restart in cron or so

Another candidate for the Bad Ideas Thread?

sam

I prefer putting reboot now in my cron jobs.

Filed under: I just farted

faoileag

@PJH said:

@Michael in his reply said:
I'm going to put service mysql restart in cron or so :)

Another candidate for the Bad Ideas Thread?

SOP if you are too lazy to find the underlying problem and fix it.

Problem: putting service mysql restart doesn't even help (at least not really), because it still means the mysql daemon can be down for a considerable amount of time (until the next time cron executes service mysql restart).

Running mysqld in a while loop like:

while [0 -lt 1]; do
  service mysql start
done;
```
would do the trick *if `service` is blocking* which I think it isn't.

So, better to try and find out *why* mysqld keeps crashing. Perhaps a bad hard disk?

PJH

@faoileag said:

would do the trick if service is blocking which I think it isn't.

From observation, service servicename action appears to be an alias for /etc/rc.d/init.d/servicename action (or whereever your init scripts live) so, no - it's not blocking.

faoileag

@codinghorror said:

Apologies for last para, you may want to close your eyes through that section.

A little late, maybe, but: no need to apologize for the last paragraph; every father is proud of his child and I definitely won't blame you for posting some praise in this community ;-)

However, you might consider apologizing to Michael for posting the second-to-last paragraph on TDWTF.

Arantor

Getting rid of InnoDB? On MySQL?

ARE YOU FUCKING INSANE?

faoileag

Never ascribe to insanity what may be explained by ordinary incompetence.

Arantor

This isn't ordinary incompetence. This is exceptional incompetence.

InnoDB was made default in MySQL a couple of versions back for a good reason. Instead of having a table type that forced a complete table lock for every write (MyISAM), let's go to a model that doesn't require entire table locks for writes and generally performs better for anything with even approaching a mild write cycle (InnoDB). The only time MyISAM outperforms InnoDB is if you're using tables that are almost or actually exclusively read only, or if you're using an older version of MySQL and need to use fulltext indexing on said table.

faoileag

I somehow doubt that Michael knows this.

Arantor

Indeed if restarting mysqld via cron is perceived as a good idea, it's small wonder.

InnoDB also is actually more reliable under those circumstances, too... MyISAM has a nasty habit of going corruptiboom in that situation.

Onyx

@Arantor said:

Getting rid of InnoDB? On MySQL?

ARE YOU FUCKING INSANE?

FOREIGN KEYS? WHAT'S THAT?

Also, everything else you said.

sam

@Arantor said:

The only time MyISAM outperforms InnoDB is if you're using tables that are almost or actually exclusively read only, or if you're using an older version of MySQL and need to use fulltext indexing on said table.

I thought one edge condition was that count(*) was faster on myisam. I think its the storage engine for people who care about performance but don't care about data.

Arantor

Oh, no, there are all kinds of things.

It's not quite that simple. COUNT(*) without any filtering will always perform best on MyISAM because it's stored directly in the table data, so it doesn't touch the table at all, something it has to do on InnoDB. But add in filtering and things get interesting.

MyISAM will unilaterally outperform InnoDB for read only loads because it doesn't have to do row level locking and things like that. But almost all loads are not read-only or predominantly read only; while MyISAM is faster at reading, the table locking bites more and more as the insert/update rate grows, and most workloads are mixed read/write loads. But it's one of those things you can play with to suit a workload; you can set it per table should you so wish.

It really does depend on workload. MyISAM isn't as resilient, true, and read performance can be fantastic. Under other circumstances, MEMORY tables might be better, too.

MySQL is strange to optimise for.

sam

dkf

@Onyx said:

FOREIGN KEYS?

I take it you're a nativist keys guy then? When you use a key, you want to see its full birth certificate (and not one of those pesky Hawaiian short ones either!) before you'll let it step foot in your codebase…

DrakeSmith

Users are scary...

Onyx

It's not me, it's MyISAM. Doesn't even ask but rather outright refuses to admit they even exist.

Arantor

It doesn't just refuse to admit they even exist. It also refuses to admit transactions exist either.

Onyx

Well of course not! They might be bringing those foreigners in!

Arantor

I bet we'll see this fixed in the new version by way of increased body scans with extra super doubleplus fungood radiation, cavity searches for all, followed by a short interview to justify your desire to come in, followed by a second interview because the first one wasn't good enough.

dkf

@Onyx said:

Well of course not! They might be bringing those foreigners in!

Or, worse still, "data integrity"!
(See those scare quotes? That means it must be a worrisome thing!)

Nagesh

@faoileag said:

Never ascribe to insanity what may be explained by ordinary incompetence.

@faoileag That is really nice way of saying things!

Arantor

I rarely find insanity comes into play. I find Hanlon's Razor works so much more often - never ascribing to malice what can be explained by incompetence, because if it isn't incompetence it's malice in my experience.

dhromed

@boomzilla said:

HHGttG jokes.

~ Hey Hey, Go titty Go ~