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 ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings
