Markus Schiltknecht <markus@bluegap.ch> wrote:
>
> Hi,
>
> Bill Moran wrote:
> > While true, I feel those applications are the exception, not the rule.
> > Most DBs these days are the blogs and the image galleries, etc. And
> > those don't need or want the overhead associated with synchronous
> > replication.
>
> Uhm.. do blogs and image galleries need replication at all?
Ever read anything on how myspace is laid out? The big ones need
replication to handle the traffic.
> I'm thinking more of the business critical applications, where high
> availability is a real demand - and where your data *should* better be
> distributed among multiple data centers just to avoid a single point of
> failure.
Agreed. Judged by importance, they're bigger. Judged by raw numbers, I
suspect that they're less prominent than the blogs and image galleries.
I guess it depends on your viewpoint.
> <rant> for most other stuff MySQL is good enough </rant>
I hate when people say that. Any company that says that is of limited
viability in my opinion. For one thing, saying it's "good enough" is
setting yourself up for trouble when your company expands its
requirements.
> > It's synchronous for the reason you describe,
> > but it's asynchronous because a query that has returned successfully
> > is not _guaranteed_ to be committed everywhere yet. Seems like we're
> > dealing with a limitation in the terminology :)
>
> Certainly! But sync and async replication are so well known and used
> terms... on the other hand, I certainly agree that in Postgres-R, the
> nodes do not process transactions synchronously, but asynchronous.
Good point.
> Maybe it's really better to speak of eager and lazy replication, as in
> some literature (namely the initial Postgres-R paper of Bettina Kemme).
>
> > This could potentially be a problem on (for example) a web application,
> > where a particular user's experience may be load-balanced to another
> > node at any time. Of course, you just have to write the application
> > with that knowledge.
>
> IMO, such heavily dynamic load-balancing is rarely useful.
>
> With application support, it's easily doable: let the first transaction
> on node A query the (global) transaction identifier and after connecting
> to the next node B, ask that to wait until that transaction has committed.
>
> It gets a little harder without application support: the load balancer
> would have to keep track of sessions and their last (writing) transaction.
>
> Again, thank you for pointing this out.
Keep up the good work. I wish I had some spare cycles to work on
Postgres-R -- it seems like a very interesting problem.
--
Bill Moran
http://www.potentialtech.com