Update failover docs, per suggestions from Chris Browne.
This commit is contained in:
parent
77f24a46b7
commit
ca21417a34
@ -1,4 +1,4 @@
|
|||||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/failover.sgml,v 1.3 2006/10/27 12:40:26 momjian Exp $ -->
|
<!-- $PostgreSQL: pgsql/doc/src/sgml/failover.sgml,v 1.4 2006/11/14 21:43:00 momjian Exp $ -->
|
||||||
|
|
||||||
<chapter id="failover">
|
<chapter id="failover">
|
||||||
<title>Failover, Replication, Load Balancing, and Clustering Options</title>
|
<title>Failover, Replication, Load Balancing, and Clustering Options</title>
|
||||||
@ -108,7 +108,7 @@
|
|||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
Slony is an example of this type of replication, with per-table
|
Slony-I is an example of this type of replication, with per-table
|
||||||
granularity. It updates the backup server in batches, so the replication
|
granularity. It updates the backup server in batches, so the replication
|
||||||
is asynchronous and might lose data during a fail over.
|
is asynchronous and might lose data during a fail over.
|
||||||
</para>
|
</para>
|
||||||
@ -138,8 +138,8 @@
|
|||||||
|
|
||||||
<para>
|
<para>
|
||||||
Data partitioning is usually handled by application code, though rules
|
Data partitioning is usually handled by application code, though rules
|
||||||
and triggers can be used to keep the read-only data sets current. Slony
|
and triggers can be used to keep the read-only data sets current. Slony-I
|
||||||
can also be used in such a setup. While Slony replicates only entire
|
can also be used in such a setup. While Slony-I replicates only entire
|
||||||
tables, London and Paris can be placed in separate tables, and
|
tables, London and Paris can be placed in separate tables, and
|
||||||
inheritance can be used to access both tables using a single table name.
|
inheritance can be used to access both tables using a single table name.
|
||||||
</para>
|
</para>
|
||||||
@ -158,11 +158,13 @@
|
|||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
This can be complex to set up because functions like random()
|
Because each server operates independently, functions like
|
||||||
and CURRENT_TIMESTAMP will have different values on different
|
<function>random()</>, <function>CURRENT_TIMESTAMP</>, and
|
||||||
servers, and sequences should be consistent across servers.
|
sequences can have different values on different servers. If
|
||||||
Care must also be taken that all transactions either commit or
|
this is unacceptable, applications must query such values from
|
||||||
abort on all servers Pgpool is an example of this type of
|
a single server and then use those values in write queries.
|
||||||
|
Also, care must also be taken that all transactions either commit
|
||||||
|
or abort on all servers Pgpool is an example of this type of
|
||||||
replication.
|
replication.
|
||||||
</para>
|
</para>
|
||||||
</sect1>
|
</sect1>
|
||||||
@ -173,13 +175,23 @@
|
|||||||
<para>
|
<para>
|
||||||
In clustering, each server can accept write requests, and these
|
In clustering, each server can accept write requests, and these
|
||||||
write requests are broadcast from the original server to all
|
write requests are broadcast from the original server to all
|
||||||
other servers before each transaction commits. Under heavy
|
other servers before each transaction commits. Heavy write
|
||||||
load, this can cause excessive locking and performance degradation.
|
activity can cause excessive locking, leading to poor performance.
|
||||||
It is implemented by <productname>Oracle</> in their
|
In fact, write performance is often worse than that of a single
|
||||||
|
server. Read requests can be sent to any server. 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 read/write and read-only servers.
|
||||||
|
</para>
|
||||||
|
|
||||||
|
<para>
|
||||||
|
Clustering is implemented by <productname>Oracle</> in their
|
||||||
<productname><acronym>RAC</></> product. <productname>PostgreSQL</>
|
<productname><acronym>RAC</></> product. <productname>PostgreSQL</>
|
||||||
does not offer this type of load balancing, though
|
does not offer this type of load balancing, though
|
||||||
<productname>PostgreSQL</> two-phase commit can be used to
|
<productname>PostgreSQL</> two-phase commit (<xref
|
||||||
implement this in application code or middleware.
|
linkend="sql-prepare-transaction-title"> and <xref linkend=
|
||||||
|
"sql-commit-prepared-title">) can be used to implement this in
|
||||||
|
application code or middleware.
|
||||||
</para>
|
</para>
|
||||||
</sect1>
|
</sect1>
|
||||||
|
|
||||||
@ -187,12 +199,12 @@
|
|||||||
<title>Clustering For Parallel Query Execution</title>
|
<title>Clustering For Parallel Query Execution</title>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
This allows multiple servers to work on a single query. One
|
This allows multiple servers to work concurrently on a single
|
||||||
possible way this could work is for the data to be split among
|
query. One possible way this could work is for the data to be
|
||||||
servers and for each server to execute its part of the query
|
split among servers and for each server to execute its part of
|
||||||
and results sent to a central server to be combined and returned
|
the query and results sent to a central server to be combined
|
||||||
to the user. There currently is no <productname>PostgreSQL</>
|
and returned to the user. There currently is no
|
||||||
open source solution for this.
|
<productname>PostgreSQL</> open source solution for this.
|
||||||
</para>
|
</para>
|
||||||
</sect1>
|
</sect1>
|
||||||
|
|
||||||
|
Loading…
x
Reference in New Issue
Block a user