From ca21417a34ce29b4b988c244e165249fdd9e106f Mon Sep 17 00:00:00 2001 From: Bruce Momjian Date: Tue, 14 Nov 2006 21:43:00 +0000 Subject: [PATCH] Update failover docs, per suggestions from Chris Browne. --- doc/src/sgml/failover.sgml | 52 +++++++++++++++++++++++--------------- 1 file changed, 32 insertions(+), 20 deletions(-) diff --git a/doc/src/sgml/failover.sgml b/doc/src/sgml/failover.sgml index 36819a2b9c..664c92f2e7 100644 --- a/doc/src/sgml/failover.sgml +++ b/doc/src/sgml/failover.sgml @@ -1,4 +1,4 @@ - + Failover, Replication, Load Balancing, and Clustering Options @@ -108,7 +108,7 @@ - Slony is an example of this type of replication, with per-table + Slony-I is an example of this type of replication, with per-table granularity. It updates the backup server in batches, so the replication is asynchronous and might lose data during a fail over. @@ -138,8 +138,8 @@ Data partitioning is usually handled by application code, though rules - and triggers can be used to keep the read-only data sets current. Slony - can also be used in such a setup. While Slony replicates only entire + and triggers can be used to keep the read-only data sets current. Slony-I + can also be used in such a setup. While Slony-I replicates only entire tables, London and Paris can be placed in separate tables, and inheritance can be used to access both tables using a single table name. @@ -158,11 +158,13 @@ - This can be complex to set up because functions like random() - and CURRENT_TIMESTAMP will have different values on different - servers, and sequences should be consistent across servers. - Care must also be taken that all transactions either commit or - abort on all servers Pgpool is an example of this type of + Because each server operates independently, functions like + random(), CURRENT_TIMESTAMP, and + sequences can have different values on different servers. If + this is unacceptable, applications must query such values from + a single server and then use those values in write queries. + Also, care must also be taken that all transactions either commit + or abort on all servers Pgpool is an example of this type of replication. @@ -173,13 +175,23 @@ In clustering, each server can accept write requests, and these write requests are broadcast from the original server to all - other servers before each transaction commits. Under heavy - load, this can cause excessive locking and performance degradation. - It is implemented by Oracle in their + other servers before each transaction commits. Heavy write + activity can cause excessive locking, leading to poor performance. + In fact, write performance is often worse than that of a single + server. Read requests can be sent to any server. Clustering + is best for mostly read workloads, though its big advantage is + that any server can accept write requests --- there is no need + to partition workloads between read/write and read-only servers. + + + + Clustering is implemented by Oracle in their RAC product. PostgreSQL does not offer this type of load balancing, though - PostgreSQL two-phase commit can be used to - implement this in application code or middleware. + PostgreSQL two-phase commit ( and ) can be used to implement this in + application code or middleware. @@ -187,12 +199,12 @@ Clustering For Parallel Query Execution - This allows multiple servers to work on a single query. One - possible way this could work is for the data to be split among - servers and for each server to execute its part of the query - and results sent to a central server to be combined and returned - to the user. There currently is no PostgreSQL - open source solution for this. + This allows multiple servers to work concurrently on a single + query. One possible way this could work is for the data to be + split among servers and for each server to execute its part of + the query and results sent to a central server to be combined + and returned to the user. There currently is no + PostgreSQL open source solution for this. -- 2.40.0