From f1528b5154ed68ec37735e7125732a96aa1758e1 Mon Sep 17 00:00:00 2001 From: Bruce Momjian Date: Thu, 8 Nov 2007 19:18:23 +0000 Subject: [PATCH] Properly indent SGML file. --- doc/src/sgml/high-availability.sgml | 368 ++++++++++++++-------------- 1 file changed, 184 insertions(+), 184 deletions(-) diff --git a/doc/src/sgml/high-availability.sgml b/doc/src/sgml/high-availability.sgml index 6bb6046af3..23e1b9d966 100644 --- a/doc/src/sgml/high-availability.sgml +++ b/doc/src/sgml/high-availability.sgml @@ -1,4 +1,4 @@ - + High Availability, Load Balancing, and Replication @@ -79,45 +79,45 @@ - - 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 standby 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. - Using a network file system is also possible, though care must be - taken that the file system has full POSIX behavior (see ). One significant limitation of this - method is that if the shared disk array fails or becomes corrupt, the - primary and standby servers are both nonfunctional. Another issue is - that the standby server should never access the shared storage while - the primary server is running. - - - - - - - File System Replication - - - - A modified version of shared hardware functionality is file system - replication, where all changes to a file system are mirrored to a file - system residing on another computer. The only restriction is that - the mirroring must be done in a way that ensures the standby server - has a consistent copy of the file system — specifically, writes - to the standby must be done in the same order as those on the master. - DRBD is a popular file system replication solution for Linux. - + + 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 standby 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. + Using a network file system is also possible, though care must be + taken that the file system has full POSIX behavior (see ). One significant limitation of this + method is that if the shared disk array fails or becomes corrupt, the + primary and standby servers are both nonfunctional. Another issue is + that the standby server should never access the shared storage while + the primary server is running. + + + + + + + File System Replication + + + + A modified version of shared hardware functionality is file system + replication, where all changes to a file system are mirrored to a file + system residing on another computer. The only restriction is that + the mirroring must be done in a way that ensures the standby server + has a consistent copy of the file system — specifically, writes + to the standby must be done in the same order as those on the master. + DRBD is a popular file system replication solution for Linux. + - - - - - Warm Standby Using Point-In-Time Recovery (PITR) - - - - 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. - - - - - - Master-Slave Replication - - - - A master-slave replication setup sends all data modification - queries to the master server. The master server asynchronously - sends data changes to the slave server. The slave can answer - read-only queries while the master server is running. The - slave server is ideal for data warehouse queries. - - - - Slony-I is an example of this type of replication, with per-table - granularity, and support for multiple slaves. Because it - updates the slave server asynchronously (in batches), there is - possible data loss during fail over. - - - - - - Statement-Based Replication Middleware - - - - With statement-based replication middleware, a program intercepts - every SQL query and sends it to one or all servers. Each server - operates independently. Read-write queries are sent to all servers, - while read-only queries can be sent to just one server, allowing - the read workload to be distributed. - - - - If queries are simply broadcast unmodified, functions like - random(), CURRENT_TIMESTAMP, and - sequences would 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, either the middleware or the application - 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, perhaps - using two-phase commit ( and . - Pgpool and Sequoia are an example of this type of replication. - - - - - - Asynchronous Multi-Master Replication - - - - For servers that are not regularly connected, like laptops or - remote servers, keeping data consistent among servers is a - challenge. Using asynchronous multi-master replication, each - server works independently, and periodically communicates with - the other servers to identify conflicting transactions. The - conflicts can be resolved by users or conflict resolution rules. - - - - - - Synchronous Multi-Master Replication - - - - In synchronous multi-master replication, 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. Some implementations use shared disk - to reduce the communication overhead. Synchronous multi-master - replication 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 master and - slave servers, and because the data changes are sent from one - server to another, there is no problem with non-deterministic - functions like random(). - - - - PostgreSQL does not offer this type of replication, - though PostgreSQL two-phase commit ( and ) - can be used to implement this in application code or middleware. - - - - - - 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, with a server - in each office. If queries combining London and Paris data - are necessary, an application can query both servers, or - master/slave replication can be used to keep a read-only copy - of the other office's data on each server. - - - - - - 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. - - - + + + + + Warm Standby Using Point-In-Time Recovery (PITR) + + + + 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. + + + + + + Master-Slave Replication + + + + A master-slave replication setup sends all data modification + queries to the master server. The master server asynchronously + sends data changes to the slave server. The slave can answer + read-only queries while the master server is running. The + slave server is ideal for data warehouse queries. + + + + Slony-I is an example of this type of replication, with per-table + granularity, and support for multiple slaves. Because it + updates the slave server asynchronously (in batches), there is + possible data loss during fail over. + + + + + + Statement-Based Replication Middleware + + + + With statement-based replication middleware, a program intercepts + every SQL query and sends it to one or all servers. Each server + operates independently. Read-write queries are sent to all servers, + while read-only queries can be sent to just one server, allowing + the read workload to be distributed. + + + + If queries are simply broadcast unmodified, functions like + random(), CURRENT_TIMESTAMP, and + sequences would 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, either the middleware or the application + 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, perhaps + using two-phase commit ( and . + Pgpool and Sequoia are an example of this type of replication. + + + + + + Asynchronous Multi-Master Replication + + + + For servers that are not regularly connected, like laptops or + remote servers, keeping data consistent among servers is a + challenge. Using asynchronous multi-master replication, each + server works independently, and periodically communicates with + the other servers to identify conflicting transactions. The + conflicts can be resolved by users or conflict resolution rules. + + + + + + Synchronous Multi-Master Replication + + + + In synchronous multi-master replication, 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. Some implementations use shared disk + to reduce the communication overhead. Synchronous multi-master + replication 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 master and + slave servers, and because the data changes are sent from one + server to another, there is no problem with non-deterministic + functions like random(). + + + + PostgreSQL does not offer this type of replication, + though PostgreSQL two-phase commit ( and ) + can be used to implement this in application code or middleware. + + + + + + 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, with a server + in each office. If queries combining London and Paris data + are necessary, an application can query both servers, or + master/slave replication can be used to keep a read-only copy + of the other office's data on each server. + + + + + + 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.40.0