New async/sync multi-master headings for docs.

This commit is contained in:
Bruce Momjian 2006-11-22 04:01:40 +00:00
parent 3b0313580e
commit 8c556ce1c2
1 changed files with 19 additions and 19 deletions

View File

@ -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 &mdash; 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
&mdash; 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>