mirror/postgresql
2
0
Fork 0
mirror of https://git.postgresql.org/git/postgresql.git synced 2025-03-01 19:45:33 +08:00
Code Issues Packages Projects Releases Wiki Activity

Replace "slave" to "standby" in documentation for consistent terminology.

Browse Source 
Almost all of the terms in docs and messages were replaced, but still
remains in a few comments and README files in codes.
This commit is contained in:
Itagaki Takahiro 2010-06-07 02:01:09 +00:00
parent 2944e6ecb6
commit 3fd839950a
7 changed files with 29 additions and 29 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
doc/src/sgml/backup.sgml
View File

@ -1,4 +1,4 @@
<!-- $PostgreSQL: pgsql/doc/src/sgml/backup.sgml,v 2.155 2010/05/03 09:14:16 heikki Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/backup.sgml,v 2.156 2010/06/07 02:01:08 itagaki Exp $ -->
<chapter id="backup">
<title>Backup and Restore</title>
@ -1425,11 +1425,11 @@ pg_dumpall -p 5432 | psql -d postgres -p 6543
<para>
It is also possible to use replication methods, such as
<productname>Slony</>, to create a slave server with the updated version of
<productname>PostgreSQL</>. The slave can be on the same computer or
<productname>Slony</>, to create a standby server with the updated version of
<productname>PostgreSQL</>. The standby can be on the same computer or
a different computer. Once it has synced up with the master server
(running the older version of <productname>PostgreSQL</>), you can
switch masters and make the slave the master and shut down the older
switch masters and make the standby the master and shut down the older
database instance. Such a switch-over results in only several seconds
of downtime for an upgrade.
</para>

4
doc/src/sgml/dblink.sgml
View File

@ -1,4 +1,4 @@
<!-- $PostgreSQL: pgsql/doc/src/sgml/dblink.sgml,v 1.11 2010/04/03 07:22:53 petere Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/dblink.sgml,v 1.12 2010/06/07 02:01:08 itagaki Exp $ -->
<sect1 id="dblink">
<title>dblink</title>
@ -623,7 +623,7 @@ SELECT *
<title>Example</title>
<programlisting>
select dblink_connect('dbname=dblink_test_slave');
select dblink_connect('dbname=dblink_test_standby');
dblink_connect
----------------
OK

4
doc/src/sgml/external-projects.sgml
View File

@ -1,4 +1,4 @@
<!-- $PostgreSQL: pgsql/doc/src/sgml/external-projects.sgml,v 1.19 2007/11/14 01:58:18 tgl Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/external-projects.sgml,v 1.20 2010/06/07 02:01:08 itagaki Exp $ -->
<appendix id="external-projects">
<title>External Projects</title>
@ -240,7 +240,7 @@
<productname>PostgreSQL</> replication solutions are developed
externally. For example, <application> <ulink
url="http://www.slony.info">Slony-I</ulink></> is a popular
master/slave replication solution that is developed independently
master/standby replication solution that is developed independently
from the core project.
</para>

26
doc/src/sgml/high-availability.sgml
View File

@ -1,4 +1,4 @@
<!-- $PostgreSQL: pgsql/doc/src/sgml/high-availability.sgml,v 1.70 2010/05/29 09:01:10 heikki Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/high-availability.sgml,v 1.71 2010/06/07 02:01:08 itagaki Exp $ -->
<chapter id="high-availability">
<title>High Availability, Load Balancing, and Replication</title>
@ -161,21 +161,21 @@ protocol to make nodes agree on a serializable transactional order.
</varlistentry>
<varlistentry>
<term>Trigger-Based Master-Slave Replication</term>
<term>Trigger-Based Master-Standby Replication</term>
<listitem>
<para>
A master-slave replication setup sends all data modification
A master-standby replication setup sends all data modification
queries to the master server. The master server asynchronously
sends data changes to the slave server. The slave can answer
sends data changes to the standby server. The standby can answer
read-only queries while the master server is running. The
slave server is ideal for data warehouse queries.
standby server is ideal for data warehouse queries.
</para>
<para>
<productname>Slony-I</> is an example of this type of replication, with per-table
granularity, and support for multiple slaves. Because it
updates the slave server asynchronously (in batches), there is
granularity, and support for multiple standby servers. Because it
updates the standby server asynchronously (in batches), there is
possible data loss during fail over.
</para>
</listitem>
@ -202,9 +202,9 @@ protocol to make nodes agree on a serializable transactional order.
this is unacceptable, either the middleware or the application
must query such values from a single server and then use those
values in write queries. Another option is to use this replication
option with a traditional master-slave setup, i.e. data modification
option with a traditional master-standby setup, i.e. data modification
queries are sent only to the master and are propagated to the
slaves via master-slave replication, not by the replication
standby servers via master-standby replication, not by the replication
middleware. Care must also be taken that all
transactions either commit or abort on all servers, perhaps
using two-phase commit (<xref linkend="sql-prepare-transaction">
@ -247,7 +247,7 @@ protocol to make nodes agree on a serializable transactional order.
replication is best for mostly read workloads, though its big
advantage is that any server can accept write requests &mdash;
there is no need to partition workloads between master and
slave servers, and because the data changes are sent from one
standby servers, and because the data changes are sent from one
server to another, there is no problem with non-deterministic
functions like <function>random()</>.
</para>
@ -291,7 +291,7 @@ protocol to make nodes agree on a serializable transactional order.
<entry>Shared Disk Failover</entry>
<entry>File System Replication</entry>
<entry>Hot/Warm Standby Using PITR</entry>
<entry>Trigger-Based Master-Slave Replication</entry>
<entry>Trigger-Based Master-Standby Replication</entry>
<entry>Statement-Based Replication Middleware</entry>
<entry>Asynchronous Multimaster Replication</entry>
<entry>Synchronous Multimaster Replication</entry>
@ -378,7 +378,7 @@ protocol to make nodes agree on a serializable transactional order.
</row>
<row>
<entry>Slaves accept read-only queries</entry>
<entry>Standby accept read-only queries</entry>
<entry align="center"></entry>
<entry align="center"></entry>
<entry align="center">Hot only</entry>
@ -430,7 +430,7 @@ protocol to make nodes agree on a serializable transactional order.
partitioned by offices, e.g., London and Paris, with a server
in each office. If queries combining London and Paris data
are necessary, an application can query both servers, or
master/slave replication can be used to keep a read-only copy
master/standby replication can be used to keep a read-only copy
of the other office's data on each server.
</para>
</listitem>

6
doc/src/sgml/protocol.sgml
View File

@ -1,4 +1,4 @@
<!-- $PostgreSQL: pgsql/doc/src/sgml/protocol.sgml,v 1.88 2010/06/03 22:17:32 tgl Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/protocol.sgml,v 1.89 2010/06/07 02:01:08 itagaki Exp $ -->
<chapter id="protocol">
<title>Frontend/Backend Protocol</title>
@ -1315,7 +1315,7 @@ The commands accepted in walsender mode are:
<para>
The unique system identifier identifying the cluster. This
can be used to check that the base backup used to initialize the
slave came from the same cluster.
standby came from the same cluster.
</para>
</listitem>
</varlistentry>
@ -1326,7 +1326,7 @@ The commands accepted in walsender mode are:
</term>
<listitem>
<para>
Current TimelineID. Also useful to check that the slave is
Current TimelineID. Also useful to check that the standby is
consistent with the master.
</para>
</listitem>

4
doc/src/sgml/release-9.0.sgml
View File

@ -1,4 +1,4 @@
<!-- $PostgreSQL: pgsql/doc/src/sgml/release-9.0.sgml,v 2.27 2010/06/03 21:23:02 tgl Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/release-9.0.sgml,v 2.28 2010/06/07 02:01:08 itagaki Exp $ -->
<sect1 id="release-9-0">
<title>Release 9.0</title>
@ -398,7 +398,7 @@ recovery_connections -> hot_standby
<para>
Previously <acronym>WAL</> files could be sent to standby systems only
as 16 megabytes files; this allows master changes to be sent to the
slave with very little delay. There are new <filename>postgresql.conf</>
standby with very little delay. There are new <filename>postgresql.conf</>
and <filename>recovery.conf</> settings to enable this
feature, as well as extensive <link
linkend="streaming-replication">documentation</link>.

6
doc/src/sgml/release-alpha.sgml
View File

@ -1,4 +1,4 @@
<!-- $PostgreSQL: pgsql/doc/src/sgml/release-alpha.sgml,v 2.1 2010/04/29 20:54:28 momjian Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/release-alpha.sgml,v 2.2 2010/06/07 02:01:09 itagaki Exp $ -->
<sect1 id="release-9-0-alpha">
<title>Release 9.0alpha4</title>
@ -126,7 +126,7 @@
<emphasis>This implementation should be significantly more
efficient than the old one, and is also more compatible with
Hot Standby usage. There is not yet any facility for HS
slaves to receive notifications generated on the master,
standby servers to receive notifications generated on the master,
although such a thing is possible in future.</emphasis>
</para>
</listitem>
@ -552,7 +552,7 @@
<listitem>
<para>
Allow read-only connections during recovery, also
known as Hot Standby. This provides a built-in master-slave
known as Hot Standby. This provides a built-in master-standby
replication solution.
</para>
</listitem>