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:00:19 +00:00
parent ffa0e8f0cd
commit 3b0313580e
1 changed files with 15 additions and 15 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

30
doc/src/sgml/high-availability.sgml
View File

@ -1,4 +1,4 @@
<!-- $PostgreSQL: pgsql/doc/src/sgml/high-availability.sgml,v 1.9 2006/11/22 03:44:52 momjian Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/high-availability.sgml,v 1.10 2006/11/22 04:00:19 momjian Exp $ -->
<chapter id="high-availability">
<title>High Availability and Load Balancing</title>
@ -184,22 +184,22 @@ protocol to make nodes agree on a serializable transactional order.
</varlistentry>
<varlistentry>
<term>Multi-Master Clustering</term>
<term>Multi-Master Replication</term>
<listitem>
<para>
In clustering, 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,
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()</>.
</para>
@ -246,7 +246,7 @@ protocol to make nodes agree on a serializable transactional order.
</varlistentry>
<varlistentry>
<term>Clustering For Parallel Query Execution</term>
<term>Multi-Server Parallel Query Execution</term>
<listitem>
<para>