|
1 | | -<!-- $PostgreSQL: pgsql/doc/src/sgml/high-availability.sgml,v 1.8 2006/11/21 22:48:33 momjian Exp $ --> |
| 1 | +<!-- $PostgreSQL: pgsql/doc/src/sgml/high-availability.sgml,v 1.9 2006/11/22 03:44:52 momjian Exp $ --> |
2 | 2 |
|
3 | 3 | <chapter id="high-availability"> |
4 | 4 | <title>High Availability and Load Balancing</title> |
@@ -193,11 +193,13 @@ protocol to make nodes agree on a serializable transactional order. |
193 | 193 | other server before each transaction commits. Heavy write |
194 | 194 | activity can cause excessive locking, leading to poor performance. |
195 | 195 | In fact, write performance is often worse than that of a single |
196 | | - server. Read requests can be sent to any server. Clustering |
197 | | - is best for mostly read workloads, though its big advantage |
198 | | - is that any server can accept write requests — there is |
199 | | - no need to partition workloads between master and slave servers, |
200 | | - and because the data changes are sent from one server to another, |
| 196 | + server. Read requests can be sent to any server. Some |
| 197 | + implementations use cluster-wide shared memory or shared disk |
| 198 | + to reduce the communication overhead. Clustering is best for |
| 199 | + mostly read workloads, though its big advantage is that any |
| 200 | + server can accept write requests — there is no need to |
| 201 | + partition workloads between master and slave servers, and |
| 202 | + because the data changes are sent from one server to another, |
201 | 203 | there is no problem with non-deterministic functions like |
202 | 204 | <function>random()</>. |
203 | 205 | </para> |
|