On 6/1/07, Chris Browne <cbbrowne@xxxxxxx> wrote:
There would be *some* scalability gains to be had, but the primary reason for looking for multimaster replication is that you need high availability so badly that you are willing to give up performance to get it.
...dependent on some specific definition of "multimaster". I note that the MySQL people happily use "multimaster replication" to mean a master/slave setup where masters are also slaves, and conflicts are supposedly handled by assuming that the user always assigns unique IDs to new rows. That's not necessarily my definition.
> As it stands today, horizontally partitioning a database into multiple > separate "shards" is incredibly invasive on the application > architecture, and typically relies on brittle and non-obvious hacks > such as configuring sequence generators with staggered starting > numbers, omitting referential integrity constraints, sacrificing > transactional semantics, and moving query aggregation into the app > level. On top of this, dumb caches such as Memcached are typically > layered to avoid hitting the database in the first place. Question: In what way would you expect an attempt to do mostly-trying-to-be-transparent multimaster replication to help with these issues you're bringing up?
I don't expect anything. What I said was: "I think we could be more productive by rephrasing the question 'how/when we can implement multimaster replication?' as 'how/when can we implement horizontal scaling?'". Which means we're in agreement when you say:
Partitioning isn't multimaster replication; it's something worthy of having a discussion independent of anything about MMR.
Alexander.
