Mysql master<->master replication getting entirely messed up. What config do I need to tweak?

[Tomas Doran]

On Wed, 2008-04-09 at 16:05 -0700, J. Shirley wrote:
> Just out of curiosity, have any production installations attempted to
> run on a MySQL Cluster (NDB  Cluster)?  It seems like a slightly safer
> method for scaling upwards without having to deal with a 3rd party HA
> VIP setup.

Don't do it - it's a good idea but not production ready, and it's
failure modes are abysmal. My last company made this mistake with the
metadata for their cache subsystem (the actual cache items are in
memcache), and regretted it - they're now using 4 boxes running InnoDB
(no replication) with the data sharded across the 4 boxen. As this is a
cache system - they can lose chunks of data and that's ok(ish - there is
handling for it falling over that was built as ndb kept falling over) ;)

Some of the bad things, in quick form:
 * When it crashes, it *all* crashes. Crashing it is easy - have 2
connections truncate the same table at the same time.
 * Restarting a crashed cluster takes *AGES*.
 * If you can deal with data loss then re-initing the cluster is much
quicker. But when you bring it back up, it will fall over - 3/4 threads
all saying SELECT stuff FROM non_existent_table will bring the cluster
to it's knees, so you'll never be able to recreate your tables.
 * Unless your dataset is static, then you're doomed - it never frees
memory from deleted rows - the only way to free dead rows is to truncate
a table.

Cheers
Tom