4 ms·

Has anyone here used MySQL Cluster in production?

by pc 15y ago

bermanoid 15y ago
I'm also very curious to hear real world feedback on this, I've been aware of the option for a while, but never heard much about actual use. Automatic sharding and memcached integration are pretty awesome features, and could definitely ease code at the application level (sharding code is a particularly special pain in the ass, not so much getting it working, but allowing for re-sharding migrations if you decide you need more shards, especially trying to do so without downtime which involves all sorts of nasty tradeoffs). But bang-for-the-buck and reliability wise, I'm still unsure, I've heard very little about this in the wild. Is this more suited for high write v. read ratio situations, or is it aiming more at the Vertica/Greenplum big-data uses, or something else?
- HarrisonFisk 15y ago
  It is more suited for realtime transaction processing type activity, not for big data type analytics. NDB was originally created by and for telecoms. So very high write/read rates with very fast response times and very high availability required. Generally not extremely large datasets. If you know what you are doing, NDB can work extremely well. It supports all of the highend cluster goodies including online software upgrade, online node addition, automatic handling of node failures, geographic async replication, etc... However, it certainly has a pretty steep learning curve from the admin point of view and it is a bit easy to mess things up. It is a bit brittle due to this, but once it is setup properly and running, it can deliver on the promises.
- seanp2k2 15y ago
  MySQL is an expensive toy if you spring for Enterprise. Crashes all over the place, bugs stay open forever, no one really knows how to fix it, people on IRC are mean and think they know more than they do, etc. Check out Postgres or Cassandra.
- macros 15y ago
  We've been happily using it for the better part of a year now. Our data set fits easily in memory and the limitations of the product aren't a problem at all. We started with riak but the cognitive overhead on the developer side was a bit much for the operations side win, mysql cluster has been trouble free so far.
viraptor 15y ago
I did try around the time it split from the normal releases (6.0?). The overall feeling I got was that lots of simple things don't work, trivial bugs stay open for... well mine are still open and there was next to no documentation for any kind of troubleshooting. NDB returned error numbers which were not properly translated by mysql_error, so you were left looking them up the hard way. There was also next to no community - just one IRC channel where guru ndb hackers seemed to know everything about it... but any kind of debugging through them was pretty hard if you ended up with a "I've got a XXGB db which just doesn't come up, what do I do?" situation. If this has improved lately, I'd be very interested to hear about the changes!
- pc 15y ago
  Yeah, that was pretty much exactly my experience last time I tried it. (Around version 7.1 / mid-2010, I think.)
  - moe 15y ago
    Ditto (early 2010). Since our complexity requirements were low we settled for a home-grown solution (basically memcached with write-through) and so far didn't regret. I, too, remain curious if anyone is running this at scale and has bumped into the various corner cases (exceeding capacity, hardware dying, etc.).
kungfooguru 15y ago
Yes. And its a pain in the ass. From reading whats new in this release I could care less about AQL but hearing them say you can bring up a whole cluster with one command it shares user permissions between them... that gets me excited!
- orthecreedence 15y ago
  I played around it with in some of our apps, and I can second that running it was a pain in the ass. It seemed to fail randomly (the entire cluster would go down) even with minimal use. I know I must have been doing something horribly wrong, but I never could really figure out what it was.
martindale 15y ago
Yes; ran quite well with around 16GB of data in three nodegroups of two replicas each. Rolling restarts for making configuration changes (including the expansion of the cluster) were a total blessing. We peaked around 2,000 queries per second, and maintained (with a good indexing strategy) < 0.01s average query time using the SQL layer.

Has anyone here used MySQL Cluster in production?

by pc 15y ago

Has anyone here used MySQL Cluster in production?

I'm also very curious to hear real world feedback on this, I've been aware of the option for a while, but never heard much about actual use. Automatic sharding and memcached integration are pretty awesome features, and could definitely ease code at the application level (sharding code is a particularly special pain in the ass, not so much getting it working, but allowing for re-sharding migrations if you decide you need more shards, especially trying to do so without downtime which involves all sorts of nasty tradeoffs). But bang-for-the-buck and reliability wise, I'm still unsure, I've heard very little about this in the wild. Is this more suited for high write v. read ratio situations, or is it aiming more at the Vertica/Greenplum big-data uses, or something else?

HarrisonFisk 15y ago
It is more suited for realtime transaction processing type activity, not for big data type analytics. NDB was originally created by and for telecoms. So very high write/read rates with very fast response times and very high availability required. Generally not extremely large datasets. If you know what you are doing, NDB can work extremely well. It supports all of the highend cluster goodies including online software upgrade, online node addition, automatic handling of node failures, geographic async replication, etc... However, it certainly has a pretty steep learning curve from the admin point of view and it is a bit easy to mess things up. It is a bit brittle due to this, but once it is setup properly and running, it can deliver on the promises.
seanp2k2 15y ago
MySQL is an expensive toy if you spring for Enterprise. Crashes all over the place, bugs stay open forever, no one really knows how to fix it, people on IRC are mean and think they know more than they do, etc. Check out Postgres or Cassandra.
macros 15y ago
We've been happily using it for the better part of a year now. Our data set fits easily in memory and the limitations of the product aren't a problem at all. We started with riak but the cognitive overhead on the developer side was a bit much for the operations side win, mysql cluster has been trouble free so far.

viraptor 15y ago

I did try around the time it split from the normal releases (6.0?). The overall feeling I got was that lots of simple things don't work, trivial bugs stay open for... well mine are still open and there was next to no documentation for any kind of troubleshooting. NDB returned error numbers which were not properly translated by mysql_error, so you were left looking them up the hard way. There was also next to no community - just one IRC channel where guru ndb hackers seemed to know everything about it... but any kind of debugging through them was pretty hard if you ended up with a "I've got a XXGB db which just doesn't come up, what do I do?" situation. If this has improved lately, I'd be very interested to hear about the changes!

pc 15y ago
Yeah, that was pretty much exactly my experience last time I tried it. (Around version 7.1 / mid-2010, I think.)
- moe 15y ago
  Ditto (early 2010). Since our complexity requirements were low we settled for a home-grown solution (basically memcached with write-through) and so far didn't regret. I, too, remain curious if anyone is running this at scale and has bumped into the various corner cases (exceeding capacity, hardware dying, etc.).

kungfooguru 15y ago

Yes. And its a pain in the ass. From reading whats new in this release I could care less about AQL but hearing them say you can bring up a whole cluster with one command it shares user permissions between them... that gets me excited!

orthecreedence 15y ago
I played around it with in some of our apps, and I can second that running it was a pain in the ass. It seemed to fail randomly (the entire cluster would go down) even with minimal use. I know I must have been doing something horribly wrong, but I never could really figure out what it was.

martindale 15y ago

Yes; ran quite well with around 16GB of data in three nodegroups of two replicas each. Rolling restarts for making configuration changes (including the expansion of the cluster) were a total blessing. We peaked around 2,000 queries per second, and maintained (with a good indexing strategy) < 0.01s average query time using the SQL layer.