|
1 |
| -<!-- $PostgreSQL: pgsql/doc/src/sgml/high-availability.sgml,v 1.37 2010/02/03 17:25:05 momjian Exp $ --> |
| 1 | +<!-- $PostgreSQL: pgsql/doc/src/sgml/high-availability.sgml,v 1.38 2010/02/05 23:53:22 momjian Exp $ --> |
2 | 2 |
|
3 | 3 | <chapter id="high-availability">
|
4 | 4 | <title>High Availability, Load Balancing, and Replication</title>
|
@@ -135,21 +135,22 @@ protocol to make nodes agree on a serializable transactional order.
|
135 | 135 | </varlistentry>
|
136 | 136 |
|
137 | 137 | <varlistentry>
|
138 |
| - <term>Warm Standby Using Point-In-Time Recovery (<acronym>PITR</>)</term> |
| 138 | + <term>Warm and Hot Standby Using Point-In-Time Recovery (<acronym>PITR</>)</term> |
139 | 139 | <listitem>
|
140 | 140 |
|
141 | 141 | <para>
|
142 |
| - A warm standby server (see <xref linkend="warm-standby">) can |
143 |
| - be kept current by reading a stream of write-ahead log (<acronym>WAL</>) |
| 142 | + Warm and hot standby servers can be kept current by reading a |
| 143 | + stream of write-ahead log (<acronym>WAL</>) |
144 | 144 | records. If the main server fails, the warm standby contains
|
145 | 145 | almost all of the data of the main server, and can be quickly
|
146 | 146 | made the new master database server. This is asynchronous and
|
147 | 147 | can only be done for the entire database server.
|
148 | 148 | </para>
|
149 | 149 | <para>
|
150 |
| - A PITR warm standby server can be kept more up-to-date using the |
151 |
| - streaming replication feature built into <productname>PostgreSQL</> 8.5 |
152 |
| - onwards; see <xref linkend="warm-standby">. |
| 150 | + A PITR standby server can be kept more up-to-date using streaming |
| 151 | + replication.; see <xref linkend="streaming-replication">. For |
| 152 | + warm standby information, see <xref linkend="warm-standby">, and |
| 153 | + for hot standby, see <xref linkend="hot-standby">. |
153 | 154 | </para>
|
154 | 155 | </listitem>
|
155 | 156 | </varlistentry>
|
|
0 commit comments