mirrors/postgres
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

New async/sync multi-master headings for docs.

Browse Source
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
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

38
doc/src/sgml/high-availability.sgml
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"> <chapter id="high-availability">
<title>High Availability and Load Balancing</title> <title>High Availability and Load Balancing</title>
@ -133,11 +133,11 @@ protocol to make nodes agree on a serializable transactional order.
</varlistentry> </varlistentry>
<varlistentry> <varlistentry>
<term>Master/Slave Replication</term> <term>Master-Slave Replication</term>
<listitem> <listitem>
<para> <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 queries to the master server. The master server asynchronously
sends data changes to the slave server. The slave can answer sends data changes to the slave server. The slave can answer
read-only queries while the master server is running. The 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>
<varlistentry> <varlistentry>
<term>Multi-Master Replication</term> <term>Synchonous Multi-Master Replication</term>
<listitem> <listitem>
<para> <para>
In multi-master replication, each server can accept write In synchonous multi-master replication, each server can accept
requests, and modified data is transmitted from the original write requests, and modified data is transmitted from the
server to every other server before each transaction commits. original server to every other server before each transaction
Heavy write activity can cause excessive locking, leading to commits. Heavy write activity can cause excessive locking,
poor performance. In fact, write performance is often worse leading to poor performance. In fact, write performance is
than that of a single server. Read requests can be sent to often worse than that of a single server. Read requests can
any server. Some implementations use cluster-wide shared memory be sent to any server. Some implementations use cluster-wide
or shared disk to reduce the communication overhead. Clustering shared memory or shared disk to reduce the communication
is best for mostly read workloads, though its big advantage is overhead. Clustering is best for mostly read workloads, though
that any server can accept write requests &mdash; there is no its big advantage is that any server can accept write requests
need to partition workloads between master and slave servers, &mdash; there is no need to partition workloads between master
and because the data changes are sent from one server to another, and slave servers, and because the data changes are sent from
there is no problem with non-deterministic functions like one server to another, there is no problem with non-deterministic
<function>random()</>. functions like <function>random()</>.
</para> </para>
<para> <para>
@ -216,7 +216,7 @@ protocol to make nodes agree on a serializable transactional order.
</varlistentry> </varlistentry>
<varlistentry> <varlistentry>
<term>Multi-Master With Conflict Resolution</term> <term>Asynchronous Multi-Master Replication</term>
<listitem> <listitem>
<para> <para>