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

[dormando]

I'm not entirely sure I'd write it off as non production ready, you just 
have to be really, really careful about setting it up. With mogilefs 
just having a master<->master setup and caching paths outside of the 
tracker will let you scale past anything I've built.

For HA it should still be fine... an HA VIP actually works okay. It'd be 
even better if an internal mechanism could help it along, but it does 
fine with minimal loss.

I think we'll be adding more internal memcached usage (and some other 
stuff I don't feel comfy addmitting to co-designing yet) which will 
reduce the database load a ton further. So, eh? If you're really blowing 
it up please ping the list and we can discuss partitioning.

-Dormando

Tomas Doran wrote:
> 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
> 
>