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?
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.
<rant> for most other stuff MySQL is good enough </rant>
I find that line fuzzy.
Yeah, it is.
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.
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.
Regards
Markus
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
