Hi,
Bill Moran wrote:
I'm curious as to how Postgres-R would handle a situation where the
constant throughput exceeded the processing speed of one of the nodes.
Well, what do you expect to happen? This case is easily detectable, but
I can only see two possible solutions: either stop the node which is to
slow or stop accepting new transactions for a while.
This technique is not meant to allow nodes to lag behind several
thousands of transactions - that should better be avoided. Rather it's
meant to decrease the commit delay necessary for synchronous replication.
I can see your system working if it's just spike loads and the slow
nodes can catch up during slow periods, but I'm wondering about the
scenarios where an admin has underestimated the hardware requirements
and one or more nodes is unable to keep up.
Please keep in mind, that replication per se does not speed your
database up, it rather adds a layer of reliability, which *costs* some
performance. To increase the transactional throughput you would need to
add partitioning to the mix. Or you could try to make use of the gained
reliability and abandon WAL - you won't need that as long as at least
one replica is running - that should increase the single node's
throughput and therefore the cluster's throughput, too.
When replication meets partitioning and load balancing, you'll get into
a whole new world, where new trade-offs need to be considered. Some look
similar to those with RAID storage - probably Sequoia's term RAIDb isn't
bad at all.
Regards
Markus
---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
