I'm looking for some feedback on using mysql cluster and rails. I've
developed an app using innoDB and have all the foreign key constraints
set up on the database for pretty much everything and I'm using lots of
cascading. Come to find out the ndb storage engine does not support
constraints and triggers are not an option. The cluster was in the
works before my prescence, thus I did not research much of it.
All in all, I have 100+ tables and this is not everything converted
(legacy app). I can't see maintaining triggers for this to be
successful and I'd rather drop all constraints all together than
I know rails in itself maintains the integrity, but I cannot rely on
rails to be the only app talking to the database. REST or web services
will be adressed, but at this point it's not an option. Even so, I like
to have the constraints on the database to prevent strange errors with
orphaned data in the tables.
Anyone have some experience in this matter?
Happy new year to all 6000 members of this forum.
You sure that nobody can shed some light on this topic?
Your question is fairly vague, but we're using rails w/ MySQL cluster.
It works just like a regular rails app (a typical database.yml).
Be warned that MySQL is not as stable as the regular MySQL server. We
have reoccurring problems and find bugs for the MySQL developers too
often. They're constantly releasing new builds and bug fixes, but
it's still quite irritating. We have thought many times about
abandoning the cluster setup altogether.
There are several limitations when comparing the cluster server to standard:
Thanks for that link. No alter tables on the ndbcluster engine is quite
interesting. We're a 24/7 shop.
I think my question is more database design related than ror and I
should probably find another forum. I really do not want to remove all
constraints on the database, but the cluster would force me to do so.
Guess I'm looking for someone to give me a reason why this would be ok.
Splitting (innoDB, myISAM and NDB tables) the data between the data
node and the query node would be an option, but then we would not
utilize the cluster as designed and only the really large datasets
would go on the cluster.
We have a non-cluster DB with InnoDB/MyISAM tables for
archive/non-essential. We have 100mil+ rows sitting there - the
cluster grinded to a hault when we tryied to query through that much
We too are a 24/7 shop and the schema change issue is huge. Rails
migrations are very nice and tidy until you try running them on a
MySQL cluster. It _can_ work without all the acrobatics outlined in
the manuals, but (as we've found) it's not bulletproof - sometimes
your cluster goes down after a simple schema change (ridiculous I
As far as contraints, Rails handles most of them for your through AR
associations. Though I can see why you would want them, since using
Rails I just gave up using them entirely (and I don't miss them).