|
1 | | -<!-- $PostgreSQL: pgsql/doc/src/sgml/high-availability.sgml,v 1.16 2007/02/01 21:02:48 momjian Exp $ --> |
| 1 | +<!-- $PostgreSQL: pgsql/doc/src/sgml/high-availability.sgml,v 1.17 2007/11/04 19:23:24 momjian Exp $ --> |
2 | 2 |
|
3 | 3 | <chapter id="high-availability"> |
4 | | - <title>High Availability andLoad Balancing</title> |
| 4 | + <title>High Availability,Load Balancing, and Replication</title> |
5 | 5 |
|
6 | 6 | <indexterm><primary>high availability</></> |
7 | 7 | <indexterm><primary>failover</></> |
|
45 | 45 | </para> |
46 | 46 |
|
47 | 47 | <para> |
48 | | - Somefailover and load balancingsolutions are synchronous, |
| 48 | + Some solutions are synchronous, |
49 | 49 | meaning that a data-modifying transaction is not considered |
50 | 50 | committed until all servers have committed the transaction. This |
51 | 51 | guarantees that a failover will not lose any data and that all |
|
65 | 65 | </para> |
66 | 66 |
|
67 | 67 | <para> |
68 | | - Performance must be considered in anyfailover or load balancing |
69 | | -choice. There is usually atradeoff between functionality and |
| 68 | + Performance must be considered in anychoice. There is usually a |
| 69 | + tradeoff between functionality and |
70 | 70 | performance. For example, a full synchronous solution over a slow |
71 | 71 | network might cut performance by more than half, while an asynchronous |
72 | 72 | one might have a minimal performance impact. |
|