database/postgres
database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-04-27 22:56:53 +03:00
Code

Wording and term clarification for HA docs, per Markus Schiltknecht.

Browse Source
This commit is contained in:
Bruce Momjian 2006-11-22 17:36:52 +00:00
parent 84151d0644
commit 6346355a9b
1 changed files with 24 additions and 22 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

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

@ -1,4 +1,4 @@
<!-- $PostgreSQL: pgsql/doc/src/sgml/high-availability.sgml,v 1.11 2006/11/22 04:01:40 momjian Exp $ --> <!-- $PostgreSQL: pgsql/doc/src/sgml/high-availability.sgml,v 1.12 2006/11/22 17:36:52 momjian Exp $ -->
<chapter id="high-availability"> <chapter id="high-availability">
<title>High Availability and Load Balancing</title> <title>High Availability and Load Balancing</title>
@ -49,13 +49,13 @@
meaning that a data-modifying transaction is not considered meaning that a data-modifying transaction is not considered
committed until all servers have committed the transaction. This committed until all servers have committed the transaction. This
guarantees that a failover will not lose any data and that all guarantees that a failover will not lose any data and that all
load-balanced servers will return consistent results with little load-balanced servers will return consistent results no matter
propagation delay. Asynchronous updating has a delay between the which server is queried. Asynchronous updating has a delay between
time of commit and its propagation to the other servers, opening the time of commit and its propagation to the other servers,
the possibility that some transactions might be lost in the switch opening the possibility that some transactions might be lost in
to a backup server, and that load balanced servers might return the switch to a backup server, and that load balanced servers
slightly stale results. Asynchronous communication is used when might return slightly stale results. Asynchronous communication
synchronous would be too slow. is used when synchronous would be too slow.
</para> </para>
<para> <para>
@ -110,7 +110,7 @@ https://forge.continuent.org/pipermail/sequoia/2006-November/004070.html
Oracle RAC is a shared disk approach and just send cache invalidations Oracle RAC is a shared disk approach and just send cache invalidations
to other nodes but not actual data. As the disk is shared, data is to other nodes but not actual data. As the disk is shared, data is
only commited once to disk and there is a distributed locking only committed once to disk and there is a distributed locking
protocol to make nodes agree on a serializable transactional order. protocol to make nodes agree on a serializable transactional order.
--> -->
@ -178,29 +178,29 @@ protocol to make nodes agree on a serializable transactional order.
using two-phase commit (<xref linkend="sql-prepare-transaction" using two-phase commit (<xref linkend="sql-prepare-transaction"
endterm="sql-prepare-transaction-title"> and <xref endterm="sql-prepare-transaction-title"> and <xref
linkend="sql-commit-prepared" endterm="sql-commit-prepared-title">. linkend="sql-commit-prepared" endterm="sql-commit-prepared-title">.
Pgpool is an example of this type of replication. Pgpool and Sequoia are an example of this type of replication.
</para> </para>
</listitem> </listitem>
</varlistentry> </varlistentry>
<varlistentry> <varlistentry>
<term>Synchonous Multi-Master Replication</term> <term>Synchronous Multi-Master Replication</term>
<listitem> <listitem>
<para> <para>
In synchonous multi-master replication, each server can accept In synchronous multi-master replication, each server can accept
write requests, and modified data is transmitted from the write requests, and modified data is transmitted from the
original server to every other server before each transaction original server to every other server before each transaction
commits. Heavy write activity can cause excessive locking, commits. Heavy write activity can cause excessive locking,
leading to poor performance. In fact, write performance is leading to poor performance. In fact, write performance is
often worse than that of a single server. Read requests can often worse than that of a single server. Read requests can
be sent to any server. Some implementations use cluster-wide be sent to any server. Some implementations use shared disk
shared memory or shared disk to reduce the communication to reduce the communication overhead. Synchronous multi-master
overhead. Clustering is best for mostly read workloads, though replication is best for mostly read workloads, though its big
its big advantage is that any server can accept write requests advantage is that any server can accept write requests &mdash;
&mdash; there is no need to partition workloads between master there is no need to partition workloads between master and
and slave servers, and because the data changes are sent from slave servers, and because the data changes are sent from one
one server to another, there is no problem with non-deterministic server to another, there is no problem with non-deterministic
functions like <function>random()</>. functions like <function>random()</>.
</para> </para>
@ -222,9 +222,11 @@ protocol to make nodes agree on a serializable transactional order.
<para> <para>
For servers that are not regularly connected, like laptops or For servers that are not regularly connected, like laptops or
remote servers, keeping data consistent among servers is a remote servers, keeping data consistent among servers is a
challenge. One simple solution is to allow each server to challenge. Using asynchronous multi-master replication, each
modify the data, and have periodic communication compare server works independently, and periodically communicates with
databases and ask users to resolve any conflicts. the other servers to identify conflicting transactions. The
conflicts can be resolved by users or conflict resolution rules.
rules.
</para> </para>
</listitem> </listitem>
</varlistentry> </varlistentry>