Replace "slave" to "standby" in documentation for consistent terminology.
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:
parent
2944e6ecb6
commit
3fd839950a
|
@ -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">
|
<chapter id="backup">
|
||||||
<title>Backup and Restore</title>
|
<title>Backup and Restore</title>
|
||||||
|
@ -1425,11 +1425,11 @@ pg_dumpall -p 5432 | psql -d postgres -p 6543
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
It is also possible to use replication methods, such as
|
It is also possible to use replication methods, such as
|
||||||
<productname>Slony</>, to create a slave server with the updated version of
|
<productname>Slony</>, to create a standby server with the updated version of
|
||||||
<productname>PostgreSQL</>. The slave can be on the same computer or
|
<productname>PostgreSQL</>. The standby can be on the same computer or
|
||||||
a different computer. Once it has synced up with the master server
|
a different computer. Once it has synced up with the master server
|
||||||
(running the older version of <productname>PostgreSQL</>), you can
|
(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
|
database instance. Such a switch-over results in only several seconds
|
||||||
of downtime for an upgrade.
|
of downtime for an upgrade.
|
||||||
</para>
|
</para>
|
||||||
|
|
|
@ -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">
|
<sect1 id="dblink">
|
||||||
<title>dblink</title>
|
<title>dblink</title>
|
||||||
|
@ -623,7 +623,7 @@ SELECT *
|
||||||
<title>Example</title>
|
<title>Example</title>
|
||||||
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
select dblink_connect('dbname=dblink_test_slave');
|
select dblink_connect('dbname=dblink_test_standby');
|
||||||
dblink_connect
|
dblink_connect
|
||||||
----------------
|
----------------
|
||||||
OK
|
OK
|
||||||
|
|
|
@ -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">
|
<appendix id="external-projects">
|
||||||
<title>External Projects</title>
|
<title>External Projects</title>
|
||||||
|
@ -240,7 +240,7 @@
|
||||||
<productname>PostgreSQL</> replication solutions are developed
|
<productname>PostgreSQL</> replication solutions are developed
|
||||||
externally. For example, <application> <ulink
|
externally. For example, <application> <ulink
|
||||||
url="http://www.slony.info">Slony-I</ulink></> is a popular
|
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.
|
from the core project.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
|
|
|
@ -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">
|
<chapter id="high-availability">
|
||||||
<title>High Availability, Load Balancing, and Replication</title>
|
<title>High Availability, Load Balancing, and Replication</title>
|
||||||
|
@ -161,21 +161,21 @@ protocol to make nodes agree on a serializable transactional order.
|
||||||
</varlistentry>
|
</varlistentry>
|
||||||
|
|
||||||
<varlistentry>
|
<varlistentry>
|
||||||
<term>Trigger-Based Master-Slave Replication</term>
|
<term>Trigger-Based Master-Standby Replication</term>
|
||||||
<listitem>
|
<listitem>
|
||||||
|
|
||||||
<para>
|
<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
|
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
|
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>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
<productname>Slony-I</> is an example of this type of replication, with per-table
|
<productname>Slony-I</> is an example of this type of replication, with per-table
|
||||||
granularity, and support for multiple slaves. Because it
|
granularity, and support for multiple standby servers. Because it
|
||||||
updates the slave server asynchronously (in batches), there is
|
updates the standby server asynchronously (in batches), there is
|
||||||
possible data loss during fail over.
|
possible data loss during fail over.
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
@ -202,9 +202,9 @@ protocol to make nodes agree on a serializable transactional order.
|
||||||
this is unacceptable, either the middleware or the application
|
this is unacceptable, either the middleware or the application
|
||||||
must query such values from a single server and then use those
|
must query such values from a single server and then use those
|
||||||
values in write queries. Another option is to use this replication
|
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
|
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
|
middleware. Care must also be taken that all
|
||||||
transactions either commit or abort on all servers, perhaps
|
transactions either commit or abort on all servers, perhaps
|
||||||
using two-phase commit (<xref linkend="sql-prepare-transaction">
|
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
|
replication is best for mostly read workloads, though its big
|
||||||
advantage is that any server can accept write requests —
|
advantage is that any server can accept write requests —
|
||||||
there is no need to partition workloads between master and
|
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
|
server to another, there is no problem with non-deterministic
|
||||||
functions like <function>random()</>.
|
functions like <function>random()</>.
|
||||||
</para>
|
</para>
|
||||||
|
@ -291,7 +291,7 @@ protocol to make nodes agree on a serializable transactional order.
|
||||||
<entry>Shared Disk Failover</entry>
|
<entry>Shared Disk Failover</entry>
|
||||||
<entry>File System Replication</entry>
|
<entry>File System Replication</entry>
|
||||||
<entry>Hot/Warm Standby Using PITR</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>Statement-Based Replication Middleware</entry>
|
||||||
<entry>Asynchronous Multimaster Replication</entry>
|
<entry>Asynchronous Multimaster Replication</entry>
|
||||||
<entry>Synchronous Multimaster Replication</entry>
|
<entry>Synchronous Multimaster Replication</entry>
|
||||||
|
@ -378,7 +378,7 @@ protocol to make nodes agree on a serializable transactional order.
|
||||||
</row>
|
</row>
|
||||||
|
|
||||||
<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"></entry>
|
<entry align="center"></entry>
|
||||||
<entry align="center">Hot only</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
|
partitioned by offices, e.g., London and Paris, with a server
|
||||||
in each office. If queries combining London and Paris data
|
in each office. If queries combining London and Paris data
|
||||||
are necessary, an application can query both servers, or
|
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.
|
of the other office's data on each server.
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
|
|
@ -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">
|
<chapter id="protocol">
|
||||||
<title>Frontend/Backend Protocol</title>
|
<title>Frontend/Backend Protocol</title>
|
||||||
|
@ -1315,7 +1315,7 @@ The commands accepted in walsender mode are:
|
||||||
<para>
|
<para>
|
||||||
The unique system identifier identifying the cluster. This
|
The unique system identifier identifying the cluster. This
|
||||||
can be used to check that the base backup used to initialize the
|
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>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
</varlistentry>
|
</varlistentry>
|
||||||
|
@ -1326,7 +1326,7 @@ The commands accepted in walsender mode are:
|
||||||
</term>
|
</term>
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<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.
|
consistent with the master.
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
|
|
@ -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">
|
<sect1 id="release-9-0">
|
||||||
<title>Release 9.0</title>
|
<title>Release 9.0</title>
|
||||||
|
@ -398,7 +398,7 @@ recovery_connections -> hot_standby
|
||||||
<para>
|
<para>
|
||||||
Previously <acronym>WAL</> files could be sent to standby systems only
|
Previously <acronym>WAL</> files could be sent to standby systems only
|
||||||
as 16 megabytes files; this allows master changes to be sent to the
|
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
|
and <filename>recovery.conf</> settings to enable this
|
||||||
feature, as well as extensive <link
|
feature, as well as extensive <link
|
||||||
linkend="streaming-replication">documentation</link>.
|
linkend="streaming-replication">documentation</link>.
|
||||||
|
|
|
@ -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">
|
<sect1 id="release-9-0-alpha">
|
||||||
<title>Release 9.0alpha4</title>
|
<title>Release 9.0alpha4</title>
|
||||||
|
@ -126,7 +126,7 @@
|
||||||
<emphasis>This implementation should be significantly more
|
<emphasis>This implementation should be significantly more
|
||||||
efficient than the old one, and is also more compatible with
|
efficient than the old one, and is also more compatible with
|
||||||
Hot Standby usage. There is not yet any facility for HS
|
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>
|
although such a thing is possible in future.</emphasis>
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
@ -552,7 +552,7 @@
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
Allow read-only connections during recovery, also
|
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.
|
replication solution.
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
|
Loading…
Reference in a new issue