mirror of https://github.com/postgres/postgres
New async/sync multi-master headings for docs.
This commit is contained in:
parent
3b0313580e
commit
8c556ce1c2
|
@ -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>
|
||||
|
|
Loading…
Reference in New Issue