|
1 | | -<!-- $PostgreSQL: pgsql/doc/src/sgml/high-availability.sgml,v 1.62 2010/04/21 03:32:53 tgl Exp $ --> |
| 1 | +<!-- $PostgreSQL: pgsql/doc/src/sgml/high-availability.sgml,v 1.63 2010/04/26 19:09:25 momjian Exp $ --> |
2 | 2 |
|
3 | 3 | <chapter id="high-availability"> |
4 | 4 | <title>High Availability, Load Balancing, and Replication</title> |
@@ -199,7 +199,11 @@ protocol to make nodes agree on a serializable transactional order. |
199 | 199 | SQL queries are broadcast (and not actual modified rows). If |
200 | 200 | this is unacceptable, either the middleware or the application |
201 | 201 | must query such values from a single server and then use those |
202 | | - values in write queries. Also, care must be taken that all |
| 202 | + values in write queries. Another option is to use this replication |
| 203 | + option with a traditional master-slave setup, i.e. data modification |
| 204 | + queries are sent only to the master and are propogated to the |
| 205 | + slaves via master-slave replication, not by the replication |
| 206 | + middleware. Care must also be taken that all |
203 | 207 | transactions either commit or abort on all servers, perhaps |
204 | 208 | using two-phase commit (<xref linkend="sql-prepare-transaction"> |
205 | 209 | and <xref linkend="sql-commit-prepared">. |
|