1- <!-- $PostgreSQL: pgsql/doc/src/sgml/high-availability.sgml,v 1.70 2010/05/29 09 :01:10 heikki Exp $ -->
1+ <!-- $PostgreSQL: pgsql/doc/src/sgml/high-availability.sgml,v 1.71 2010/06/07 02 :01:08 itagaki Exp $ -->
22
33<chapter id="high-availability">
44 <title>High Availability, Load Balancing, and Replication</title>
@@ -161,21 +161,21 @@ protocol to make nodes agree on a serializable transactional order.
161161 </varlistentry>
162162
163163 <varlistentry>
164- <term>Trigger-Based Master-Slave Replication</term>
164+ <term>Trigger-Based Master-Standby Replication</term>
165165 <listitem>
166166
167167 <para>
168- A master-slave replication setup sends all data modification
168+ A master-standby replication setup sends all data modification
169169 queries to the master server. The master server asynchronously
170- sends data changes to theslave server. Theslave can answer
170+ sends data changes to thestandby server. Thestandby can answer
171171 read-only queries while the master server is running. The
172- slave server is ideal for data warehouse queries.
172+ standby server is ideal for data warehouse queries.
173173 </para>
174174
175175 <para>
176176 <productname>Slony-I</> is an example of this type of replication, with per-table
177- granularity, and support for multipleslaves . Because it
178- updates theslave server asynchronously (in batches), there is
177+ granularity, and support for multiplestandby servers . Because it
178+ updates thestandby server asynchronously (in batches), there is
179179 possible data loss during fail over.
180180 </para>
181181 </listitem>
@@ -202,9 +202,9 @@ protocol to make nodes agree on a serializable transactional order.
202202 this is unacceptable, either the middleware or the application
203203 must query such values from a single server and then use those
204204 values in write queries. Another option is to use this replication
205- option with a traditional master-slave setup, i.e. data modification
205+ option with a traditional master-standby setup, i.e. data modification
206206 queries are sent only to the master and are propagated to the
207- slaves via master-slave replication, not by the replication
207+ standby servers via master-standby replication, not by the replication
208208 middleware. Care must also be taken that all
209209 transactions either commit or abort on all servers, perhaps
210210 using two-phase commit (<xref linkend="sql-prepare-transaction">
@@ -247,7 +247,7 @@ protocol to make nodes agree on a serializable transactional order.
247247 replication is best for mostly read workloads, though its big
248248 advantage is that any server can accept write requests —
249249 there is no need to partition workloads between master and
250- slave servers, and because the data changes are sent from one
250+ standby servers, and because the data changes are sent from one
251251 server to another, there is no problem with non-deterministic
252252 functions like <function>random()</>.
253253 </para>
@@ -291,7 +291,7 @@ protocol to make nodes agree on a serializable transactional order.
291291 <entry>Shared Disk Failover</entry>
292292 <entry>File System Replication</entry>
293293 <entry>Hot/Warm Standby Using PITR</entry>
294- <entry>Trigger-Based Master-Slave Replication</entry>
294+ <entry>Trigger-Based Master-Standby Replication</entry>
295295 <entry>Statement-Based Replication Middleware</entry>
296296 <entry>Asynchronous Multimaster Replication</entry>
297297 <entry>Synchronous Multimaster Replication</entry>
@@ -378,7 +378,7 @@ protocol to make nodes agree on a serializable transactional order.
378378 </row>
379379
380380 <row>
381- <entry>Slaves accept read-only queries</entry>
381+ <entry>Standby accept read-only queries</entry>
382382 <entry align="center"></entry>
383383 <entry align="center"></entry>
384384 <entry align="center">Hot only</entry>
@@ -430,7 +430,7 @@ protocol to make nodes agree on a serializable transactional order.
430430 partitioned by offices, e.g., London and Paris, with a server
431431 in each office. If queries combining London and Paris data
432432 are necessary, an application can query both servers, or
433- master/slave replication can be used to keep a read-only copy
433+ master/standby replication can be used to keep a read-only copy
434434 of the other office's data on each server.
435435 </para>
436436 </listitem>