From a1e5b5c832db3afa0a10610b219cccc84e7e0a2a Mon Sep 17 00:00:00 2001 From: Bruce Momjian Date: Thu, 16 Nov 2006 21:43:33 +0000 Subject: [PATCH] Reconfigure failover/replication doc items to be varlist entries, rather than new sections, so they appear all on the same web page. --- doc/src/sgml/failover.sgml | 345 ++++++++++++++++++++++++--------------------- 1 file changed, 182 insertions(+), 163 deletions(-) diff --git a/doc/src/sgml/failover.sgml b/doc/src/sgml/failover.sgml index 901ad8e769..618d0bea9d 100644 --- a/doc/src/sgml/failover.sgml +++ b/doc/src/sgml/failover.sgml @@ -1,4 +1,4 @@ - + Failover, Replication, Load Balancing, and Clustering Options @@ -76,167 +76,186 @@ and load balancing solutions. - - Shared Disk Failover - - - Shared disk failover avoids synchronization overhead by having only one - copy of the database. It uses a single disk array that is shared by - multiple servers. If the main database server fails, the backup server - is able to mount and start the database as though it was recovering from - a database crash. This allows rapid failover with no data loss. - - - - Shared hardware functionality is common in network storage devices. One - significant limitation of this method is that if the shared disk array - fails or becomes corrupt, the primary and backup servers are both - nonfunctional. - - - - - Warm Standby Using Point-In-Time Recovery - - - A warm standby server (see ) can - be kept current by reading a stream of write-ahead log (WAL) - records. If the main server fails, the warm standby contains - almost all of the data of the main server, and can be quickly - made the new master database server. This is asynchronous and - can only be done for the entire database server. - - - - - Continuously Running Replication Server - - - A continuously running replication server allows the backup server to - answer read-only queries while the master server is running. It - receives a continuous stream of write activity from the master server. - Because the backup server can be used for read-only database requests, - it is ideal for data warehouse queries. - - - - 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. - - - - - Data Partitioning - - - Data partitioning splits tables into data sets. Each set can - be modified by only one server. For example, data can be - partitioned by offices, e.g. London and Paris. While London - and Paris servers have all data records, only London can modify - London records, and Paris can only modify Paris records. This - is similar to section above, except - that instead of having a read/write server and a read-only server, - each server has a read/write data set and a read-only data - set. - - - - Such partitioning provides both failover and load balancing. Failover - is achieved because the data resides on both servers, and this is an - ideal way to enable failover if the servers share a slow communication - channel. Load balancing is possible because read requests can go to any - of the servers, and write requests are split among the servers. Of - course, the communication to keep all the servers up-to-date adds - overhead, so ideally the write load should be low, or localized as in - the London/Paris example above. - - - - Data partitioning is usually handled by application code, though rules - 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. - - - - - Query Broadcast Load Balancing - - - Query broadcast load balancing is accomplished by having a - program intercept every SQL query and send it to all servers. - This is unique because most replication solutions have the write - server propagate its changes to the other servers. With query - broadcasting, each server operates independently. Read-only - queries can be sent to a single server because there is no need - for all servers to process it. - - - - One limitation of this solution is that functions like - random(), CURRENT_TIMESTAMP, and - sequences can have different values on different servers. This - is because each server operates independently, and because SQL - queries are broadcast (and not actual modified rows). If this - is unacceptable, applications must query such values from a - single server and then use those values in write queries. Also, - care must be taken that all transactions either commit or abort - on all servers Pgpool is an example of this type of replication. - - - - - Clustering For Load Balancing - - - In clustering, each server can accept write requests, and modified - data is transmitted from the original server to every other - server 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 ( and ) - can be used to implement this in application code or middleware. - - - - - Clustering For Parallel Query Execution - - - 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. - - - - - Commercial Solutions - - - Because PostgreSQL is open source and easily - extended, a number of companies have taken PostgreSQL - and created commercial closed-source solutions with unique - failover, replication, and load balancing capabilities. - - + + + + Shared Disk Failover + + + + Shared disk failover avoids synchronization overhead by having only one + copy of the database. It uses a single disk array that is shared by + multiple servers. If the main database server fails, the backup server + is able to mount and start the database as though it was recovering from + a database crash. This allows rapid failover with no data loss. + + + + Shared hardware functionality is common in network storage devices. One + significant limitation of this method is that if the shared disk array + fails or becomes corrupt, the primary and backup servers are both + nonfunctional. + + + + + + Warm Standby Using Point-In-Time Recovery + + + + A warm standby server (see ) can + be kept current by reading a stream of write-ahead log (WAL) + records. If the main server fails, the warm standby contains + almost all of the data of the main server, and can be quickly + made the new master database server. This is asynchronous and + can only be done for the entire database server. + + + + + + Continuously Running Replication Server + + + + A continuously running replication server allows the backup server to + answer read-only queries while the master server is running. It + receives a continuous stream of write activity from the master server. + Because the backup server can be used for read-only database requests, + it is ideal for data warehouse queries. + + + + 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. + + + + + + Data Partitioning + + + + Data partitioning splits tables into data sets. Each set can + be modified by only one server. For example, data can be + partitioned by offices, e.g. London and Paris. While London + and Paris servers have all data records, only London can modify + London records, and Paris can only modify Paris records. This + is similar to the "Continuously Running Replication Server" + item above, except that instead of having a read/write server + and a read-only server, each server has a read/write data set + and a read-only data set. + + + + Such partitioning provides both failover and load balancing. Failover + is achieved because the data resides on both servers, and this is an + ideal way to enable failover if the servers share a slow communication + channel. Load balancing is possible because read requests can go to any + of the servers, and write requests are split among the servers. Of + course, the communication to keep all the servers up-to-date adds + overhead, so ideally the write load should be low, or localized as in + the London/Paris example above. + + + + Data partitioning is usually handled by application code, though rules + 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. + + + + + + Query Broadcast Load Balancing + + + + Query broadcast load balancing is accomplished by having a + program intercept every SQL query and send it to all servers. + This is unique because most replication solutions have the write + server propagate its changes to the other servers. With query + broadcasting, each server operates independently. Read-only + queries can be sent to a single server because there is no need + for all servers to process it. + + + + One limitation of this solution is that functions like + random(), CURRENT_TIMESTAMP, and + sequences can have different values on different servers. This + is because each server operates independently, and because SQL + queries are broadcast (and not actual modified rows). If this + is unacceptable, applications must query such values from a + single server and then use those values in write queries. Also, + care must be taken that all transactions either commit or abort + on all servers Pgpool is an example of this type of replication. + + + + + + Clustering For Load Balancing + + + + In clustering, each server can accept write requests, and modified + data is transmitted from the original server to every other + server 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 ( and ) + can be used to implement this in application code or middleware. + + + + + + Clustering For Parallel Query Execution + + + + 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. + + + + + + Commercial Solutions + + + + Because PostgreSQL is open source and easily + extended, a number of companies have taken PostgreSQL + and created commercial closed-source solutions with unique + failover, replication, and load balancing capabilities. + + + + + -- 2.11.0