3 ms·

Last time I used the MySQL ndb cluster (admittedly, quite a few years ago, so things may be different now), it was a huge fail. It was extremely temperamental,

Last time I used the MySQL ndb cluster (admittedly, quite a few years ago, so things may be different now), it was a huge fail. It was extremely temperamental, very difficult to configure (the documentation wasn't particularly helpful in this regard) and would often crash out of the blue. Crashing lead to a couple very regrettable things happening: a- Starting the NDB cluster was a painful and slow process, often taking 45 minutes for very, very little data (1000's of rows). b- On crash, data was not recoverable and usually resulted in a total data loss. So those are my experiences using ndb in a production environment. Given that, I would stay as far away from it as I can. Having said that, I'm sure things have changed in the past 4-5 years, I'd just make sure you test things out properly, for an extended period of time, in production conditions and that you fully understand the configuration of the cluster and all of the little settings that impact performance and recoverability.

lsc 17y ago
on recoverability: sure you can 'repair tables' on a normal MySQL setup, but you are going to loose some rows that were cached; just like with fsck, you can make data sane, but not correct, people tell me that now MySQL 'repair table' is as good as promoting a slave these days, but when a server crashes, the hardware is suspect (unless the console log indicates something software-only, such as an oom condition.) so restoring from a slave still sounds like the way to go. The application I used it for back in the day was a Dspam server... it had millions of rows (keeping track of everyone's spam at a fair-sized ASP) Come to think of it, I never shut it down until we took it out of production. Of course, a database server that crashes, regardless of the ease of recovery, is of little utility. if it's still doing that, well, forget it. That I am unable to find people who use it is quite worrysome in this regard. The thing is, it was solid with dspam, and all the synthetic tests I threw at it many years ago. heh. I almost want to come up with some free webapp to test this. got any ideas on a webapp that would be easy to write, that would quickly attract users, and that would thrash the database? it doesn't need to make money.
- drusenko 17y ago
  So the particular crash issues we were having were not your typical MySQL crashes (which, as you correctly point out, are usually hardware-related), they were definitely software-related with ndb. Which is obviously a huge problem, especially as the data was unrecoverable. Before moving to NDB and after migrating from it, we had a solid single MySQL instance on the same hardware. Oh, the joys of premature optimization :)

lsc 17y ago

on recoverability: sure you can 'repair tables' on a normal MySQL setup, but you are going to loose some rows that were cached; just like with fsck, you can make data sane, but not correct, people tell me that now MySQL 'repair table' is as good as promoting a slave these days, but when a server crashes, the hardware is suspect (unless the console log indicates something software-only, such as an oom condition.) so restoring from a slave still sounds like the way to go. The application I used it for back in the day was a Dspam server... it had millions of rows (keeping track of everyone's spam at a fair-sized ASP) Come to think of it, I never shut it down until we took it out of production. Of course, a database server that crashes, regardless of the ease of recovery, is of little utility. if it's still doing that, well, forget it. That I am unable to find people who use it is quite worrysome in this regard. The thing is, it was solid with dspam, and all the synthetic tests I threw at it many years ago. heh. I almost want to come up with some free webapp to test this. got any ideas on a webapp that would be easy to write, that would quickly attract users, and that would thrash the database? it doesn't need to make money.

drusenko 17y ago
So the particular crash issues we were having were not your typical MySQL crashes (which, as you correctly point out, are usually hardware-related), they were definitely software-related with ndb. Which is obviously a huge problem, especially as the data was unrecoverable. Before moving to NDB and after migrating from it, we had a solid single MySQL instance on the same hardware. Oh, the joys of premature optimization :)