Properly indent SGML file.

diff --git a/doc/src/sgml/high-availability.sgml b/doc/src/sgml/high-availability.sgml
index 6bb6046af367e4c3e6f09d360ce2d6f275519167..23e1b9d966e13ab9785e7804e14428aaea043ed7 100644 (file)
--- 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 
-    linkend="creating-cluster-nfs">).  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 
+     linkend="creating-cluster-nfs">).  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 (
-    endterm="sql-prepare-transaction-title"> and 
-    linkend="sql-commit-prepared" endterm="sql-commit-prepared-title">.
-    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 (
-    linkend="sql-prepare-transaction"
-    endterm="sql-prepare-transaction-title"> and 
-    linkend="sql-commit-prepared" endterm="sql-commit-prepared-title">)
-    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 (
+     endterm="sql-prepare-transaction-title"> and 
+     linkend="sql-commit-prepared" endterm="sql-commit-prepared-title">.
+     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 (
+     linkend="sql-prepare-transaction"
+     endterm="sql-prepare-transaction-title"> and 
+     linkend="sql-commit-prepared" endterm="sql-commit-prepared-title">)
+     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.
+    
+   
+  
 
  
 




This is the main PostgreSQL git repository.
RSS
Atom



window.onload = function () {
	var tz_cookie = { name: 'gitweb_tz', expires: 14, path: '/' };
	onloadTZSetup('local', tz_cookie, 'datetime');
};