|
1 |
| -<!-- $PostgreSQL: pgsql/doc/src/sgml/failover.sgml,v 1.13 2006/11/1713:29:53 momjian Exp $ --> |
| 1 | +<!-- $PostgreSQL: pgsql/doc/src/sgml/high-availability.sgml,v 1.1 2006/11/1716:38:44 momjian Exp $ --> |
2 | 2 |
|
3 |
| -<chapter id="failover"> |
4 |
| - <title>Failover, Replication, Load Balancing,andClustering Options</title> |
| 3 | +<chapter id="high-availability"> |
| 4 | + <title>High AvailabilityandLoad Balancing</title> |
5 | 5 |
|
| 6 | + <indexterm><primary>high availability</></> |
6 | 7 | <indexterm><primary>failover</></>
|
7 | 8 | <indexterm><primary>replication</></>
|
8 | 9 | <indexterm><primary>load balancing</></>
|
9 | 10 | <indexterm><primary>clustering</></>
|
| 11 | + <indexterm><primary>data partitioning</></> |
10 | 12 |
|
11 | 13 | <para>
|
12 | 14 | Database servers can work together to allow a second server to
|
13 |
| - quickly take over if the primary server fails (failover), or to |
14 |
| - allow several computers to serve the same data (load balancing). |
15 |
| - Ideally, database servers could work together seamlessly. Web |
16 |
| - servers serving static web pages can be combined quite easily by |
17 |
| - merely load-balancing web requests to multiple machines. In |
18 |
| - fact, read-only database servers can be combined relatively easily |
19 |
| - too. Unfortunately, most database servers have a read/write mix |
20 |
| -of requests, and read/writeservers are much harder to combine. |
21 |
| - This is because though read-only data needs to be placed on each |
22 |
| -server only once, a write to any serverhas to be propagated to |
23 |
| - all servers so that future read requests to those servers return |
24 |
| - consistent results. |
| 15 | + quickly take overquicklyif the primary server fails (high |
| 16 | +availability), or toallow several computers to serve the same |
| 17 | +data (load balancing).Ideally, database servers could work |
| 18 | +together seamlessly. Webservers serving static web pages can |
| 19 | +be combined quite easily bymerely load-balancing web requests |
| 20 | +to multiple machines. Infact, read-only database servers can |
| 21 | +be combined relatively easilytoo. Unfortunately, most database |
| 22 | +servers have a read/writemix of requests, and read/write servers |
| 23 | +are much harder to combine.This is because though read-only |
| 24 | +data needs to be placed on each serveronly once, a write to any |
| 25 | +server has to be propagated toall servers so that future read |
| 26 | +requests to those servers returnconsistent results. |
25 | 27 | </para>
|
26 | 28 |
|
27 | 29 | <para>
|
28 |
| - This synchronization problem is the fundamental difficulty for servers |
29 |
| - working together. Because there is no single solution that eliminates |
30 |
| - the impact of the sync problem for all use cases, there are multiple |
31 |
| - solutions. Each solution addresses this problem in a different way, and |
32 |
| - minimizes its impact for a specific workload. |
| 30 | + This synchronization problem is the fundamental difficulty for |
| 31 | + servers working together. Because there is no single solution |
| 32 | + that eliminates the impact of the sync problem for all use cases, |
| 33 | + there are multiple solutions. Each solution addresses this |
| 34 | + problem in a different way, and minimizes its impact for a specific |
| 35 | + workload. |
33 | 36 | </para>
|
34 | 37 |
|
35 | 38 | <para>
|
|