On 6/1/07, Chris Browne <cbbrowne@acm.org> 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.