Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings

Commit3fd8399

Browse files
committed
Replace "slave" to "standby" in documentation for consistent terminology.
Almost all of the terms in docs and messages were replaced, but stillremains in a few comments and README files in codes.
1 parent2944e6e commit3fd8399

File tree

7 files changed

+29
-29
lines changed

7 files changed

+29
-29
lines changed

‎doc/src/sgml/backup.sgml

Lines changed: 4 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -1,4 +1,4 @@
1-
<!-- $PostgreSQL: pgsql/doc/src/sgml/backup.sgml,v 2.155 2010/05/03 09:14:16 heikki Exp $ -->
1+
<!-- $PostgreSQL: pgsql/doc/src/sgml/backup.sgml,v 2.156 2010/06/07 02:01:08 itagaki Exp $ -->
22

33
<chapter id="backup">
44
<title>Backup and Restore</title>
@@ -1425,11 +1425,11 @@ pg_dumpall -p 5432 | psql -d postgres -p 6543
14251425

14261426
<para>
14271427
It is also possible to use replication methods, such as
1428-
<productname>Slony</>, to create aslave server with the updated version of
1429-
<productname>PostgreSQL</>. Theslave can be on the same computer or
1428+
<productname>Slony</>, to create astandby server with the updated version of
1429+
<productname>PostgreSQL</>. Thestandby can be on the same computer or
14301430
a different computer. Once it has synced up with the master server
14311431
(running the older version of <productname>PostgreSQL</>), you can
1432-
switch masters and make theslave the master and shut down the older
1432+
switch masters and make thestandby the master and shut down the older
14331433
database instance. Such a switch-over results in only several seconds
14341434
of downtime for an upgrade.
14351435
</para>

‎doc/src/sgml/dblink.sgml

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -1,4 +1,4 @@
1-
<!-- $PostgreSQL: pgsql/doc/src/sgml/dblink.sgml,v 1.11 2010/04/03 07:22:53 petere Exp $ -->
1+
<!-- $PostgreSQL: pgsql/doc/src/sgml/dblink.sgml,v 1.12 2010/06/07 02:01:08 itagaki Exp $ -->
22

33
<sect1 id="dblink">
44
<title>dblink</title>
@@ -623,7 +623,7 @@ SELECT *
623623
<title>Example</title>
624624

625625
<programlisting>
626-
select dblink_connect('dbname=dblink_test_slave');
626+
select dblink_connect('dbname=dblink_test_standby');
627627
dblink_connect
628628
----------------
629629
OK

‎doc/src/sgml/external-projects.sgml

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -1,4 +1,4 @@
1-
<!-- $PostgreSQL: pgsql/doc/src/sgml/external-projects.sgml,v 1.19 2007/11/1401:58:18 tgl Exp $ -->
1+
<!-- $PostgreSQL: pgsql/doc/src/sgml/external-projects.sgml,v 1.20 2010/06/07 02:01:08 itagaki Exp $ -->
22

33
<appendix id="external-projects">
44
<title>External Projects</title>
@@ -240,7 +240,7 @@
240240
<productname>PostgreSQL</> replication solutions are developed
241241
externally. For example, <application> <ulink
242242
url="http://www.slony.info">Slony-I</ulink></> is a popular
243-
master/slave replication solution that is developed independently
243+
master/standby replication solution that is developed independently
244244
from the core project.
245245
</para>
246246

‎doc/src/sgml/high-availability.sgml

Lines changed: 13 additions & 13 deletions
Original file line numberDiff line numberDiff line change
@@ -1,4 +1,4 @@
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-
slavesvia master-slave replication, not by the replication
207+
standby serversvia 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 &mdash;
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>

‎doc/src/sgml/protocol.sgml

Lines changed: 3 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -1,4 +1,4 @@
1-
<!-- $PostgreSQL: pgsql/doc/src/sgml/protocol.sgml,v 1.88 2010/06/03 22:17:32 tgl Exp $ -->
1+
<!-- $PostgreSQL: pgsql/doc/src/sgml/protocol.sgml,v 1.89 2010/06/07 02:01:08 itagaki Exp $ -->
22

33
<chapter id="protocol">
44
<title>Frontend/Backend Protocol</title>
@@ -1315,7 +1315,7 @@ The commands accepted in walsender mode are:
13151315
<para>
13161316
The unique system identifier identifying the cluster. This
13171317
can be used to check that the base backup used to initialize the
1318-
slave came from the same cluster.
1318+
standby came from the same cluster.
13191319
</para>
13201320
</listitem>
13211321
</varlistentry>
@@ -1326,7 +1326,7 @@ The commands accepted in walsender mode are:
13261326
</term>
13271327
<listitem>
13281328
<para>
1329-
Current TimelineID. Also useful to check that theslave is
1329+
Current TimelineID. Also useful to check that thestandby is
13301330
consistent with the master.
13311331
</para>
13321332
</listitem>

‎doc/src/sgml/release-9.0.sgml

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -1,4 +1,4 @@
1-
<!-- $PostgreSQL: pgsql/doc/src/sgml/release-9.0.sgml,v 2.27 2010/06/03 21:23:02 tgl Exp $ -->
1+
<!-- $PostgreSQL: pgsql/doc/src/sgml/release-9.0.sgml,v 2.28 2010/06/07 02:01:08 itagaki Exp $ -->
22

33
<sect1 id="release-9-0">
44
<title>Release 9.0</title>
@@ -398,7 +398,7 @@ recovery_connections -> hot_standby
398398
<para>
399399
Previously <acronym>WAL</> files could be sent to standby systems only
400400
as 16 megabytes files; this allows master changes to be sent to the
401-
slave with very little delay. There are new <filename>postgresql.conf</>
401+
standby with very little delay. There are new <filename>postgresql.conf</>
402402
and <filename>recovery.conf</> settings to enable this
403403
feature, as well as extensive <link
404404
linkend="streaming-replication">documentation</link>.

‎doc/src/sgml/release-alpha.sgml

Lines changed: 3 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -1,4 +1,4 @@
1-
<!-- $PostgreSQL: pgsql/doc/src/sgml/release-alpha.sgml,v 2.1 2010/04/29 20:54:28 momjian Exp $ -->
1+
<!-- $PostgreSQL: pgsql/doc/src/sgml/release-alpha.sgml,v 2.2 2010/06/07 02:01:09 itagaki Exp $ -->
22

33
<sect1 id="release-9-0-alpha">
44
<title>Release 9.0alpha4</title>
@@ -126,7 +126,7 @@
126126
<emphasis>This implementation should be significantly more
127127
efficient than the old one, and is also more compatible with
128128
Hot Standby usage. There is not yet any facility for HS
129-
slaves to receive notifications generated on the master,
129+
standby servers to receive notifications generated on the master,
130130
although such a thing is possible in future.</emphasis>
131131
</para>
132132
</listitem>
@@ -552,7 +552,7 @@
552552
<listitem>
553553
<para>
554554
Allow read-only connections during recovery, also
555-
known as Hot Standby. This provides a built-in master-slave
555+
known as Hot Standby. This provides a built-in master-standby
556556
replication solution.
557557
</para>
558558
</listitem>

0 commit comments

Comments
 (0)
[8]ページ先頭
©2009-2025 Movatter.jp