diff options
| -rw-r--r-- | doc/src/sgml/high-availability.sgml | 38 |
1 files changed, 19 insertions, 19 deletions
diff --git a/doc/src/sgml/high-availability.sgml b/doc/src/sgml/high-availability.sgml index bc09f40c584..9e2adbaab2c 100644 --- a/doc/src/sgml/high-availability.sgml +++ b/doc/src/sgml/high-availability.sgml @@ -1,4 +1,4 @@ -<!-- $PostgreSQL: pgsql/doc/src/sgml/high-availability.sgml,v 1.10 2006/11/22 04:00:19 momjian Exp $ --> +<!-- $PostgreSQL: pgsql/doc/src/sgml/high-availability.sgml,v 1.11 2006/11/22 04:01:40 momjian Exp $ --> <chapter id="high-availability"> <title>High Availability and Load Balancing</title> @@ -133,11 +133,11 @@ protocol to make nodes agree on a serializable transactional order. </varlistentry> <varlistentry> - <term>Master/Slave Replication</term> + <term>Master-Slave Replication</term> <listitem> <para> - A master/slave replication setup sends all data modification + 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 @@ -184,24 +184,24 @@ protocol to make nodes agree on a serializable transactional order. </varlistentry> <varlistentry> - <term>Multi-Master Replication</term> + <term>Synchonous Multi-Master Replication</term> <listitem> <para> - In 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 cluster-wide shared memory - or shared disk to reduce the communication overhead. 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 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 - <function>random()</>. + In synchonous 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 cluster-wide + shared memory or shared disk to reduce the communication + overhead. 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 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 <function>random()</>. </para> <para> @@ -216,7 +216,7 @@ protocol to make nodes agree on a serializable transactional order. </varlistentry> <varlistentry> - <term>Multi-Master With Conflict Resolution</term> + <term>Asynchronous Multi-Master Replication</term> <listitem> <para> |