Hi,
David Fetter wrote:
> Very few people actually need synchronous replication, and those who
> do buy Oracle's RAC (and curse it) or use DB2's offering (and also
> curse it ;). For most purposes, fast asynchronous replication is good
> enough.
While this is certainly true, please keep in mind that async replication
always brings up the potential of conflicts, per definition - no matter
how fast it is.
IMO, it would often be a lot simpler and less expensive to use sync
replication and bite the bullet of a small commit delay (depending on
the interconnect) - but not having to deal with conflicts.
OTOH, of course there's no real (at least no OSS) solution to sync
replication, so this is just theory. I'm trying to change that with
Postgres-R [1].
As a second note, I might add that all of this really only applies to
writing transactions. Read-only transactions are, of course, not
affected by replication and can be balanced across multiple servers with
both types of replication. Only sync replication guarantees consistent
snapshots, though. Which is the reason for conflicts...
But again, this is just gray theory. And practically speaking, I'm
giving you the same general advice: prefer async replication, because
there are solutions, which are mature and used in production.
Regards
Markus
[1]: For more information, see: www.postgres-r.org
