From 3fd839950a33a7d36ac83edf1f9cc6fb929d7649 Mon Sep 17 00:00:00 2001 From: Itagaki Takahiro Date: Mon, 7 Jun 2010 02:01:09 +0000 Subject: [PATCH] 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. --- doc/src/sgml/backup.sgml | 8 ++++---- doc/src/sgml/dblink.sgml | 4 ++-- doc/src/sgml/external-projects.sgml | 4 ++-- doc/src/sgml/high-availability.sgml | 26 +++++++++++++------------- doc/src/sgml/protocol.sgml | 6 +++--- doc/src/sgml/release-9.0.sgml | 4 ++-- doc/src/sgml/release-alpha.sgml | 6 +++--- 7 files changed, 29 insertions(+), 29 deletions(-) diff --git a/doc/src/sgml/backup.sgml b/doc/src/sgml/backup.sgml index 624adb9d6d..2f271efc4c 100644 --- a/doc/src/sgml/backup.sgml +++ b/doc/src/sgml/backup.sgml @@ -1,4 +1,4 @@ - + Backup and Restore @@ -1425,11 +1425,11 @@ pg_dumpall -p 5432 | psql -d postgres -p 6543 It is also possible to use replication methods, such as - Slony, to create a slave server with the updated version of - PostgreSQL. The slave can be on the same computer or + Slony, to create a standby server with the updated version of + 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 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. diff --git a/doc/src/sgml/dblink.sgml b/doc/src/sgml/dblink.sgml index d90ea59982..81f23a28f3 100644 --- a/doc/src/sgml/dblink.sgml +++ b/doc/src/sgml/dblink.sgml @@ -1,4 +1,4 @@ - + dblink @@ -623,7 +623,7 @@ SELECT * Example - select dblink_connect('dbname=dblink_test_slave'); + select dblink_connect('dbname=dblink_test_standby'); dblink_connect ---------------- OK diff --git a/doc/src/sgml/external-projects.sgml b/doc/src/sgml/external-projects.sgml index bcc2e018cd..7e647cc985 100644 --- a/doc/src/sgml/external-projects.sgml +++ b/doc/src/sgml/external-projects.sgml @@ -1,4 +1,4 @@ - + External Projects @@ -240,7 +240,7 @@ PostgreSQL replication solutions are developed externally. For example, Slony-I is a popular - master/slave replication solution that is developed independently + master/standby replication solution that is developed independently from the core project. diff --git a/doc/src/sgml/high-availability.sgml b/doc/src/sgml/high-availability.sgml index 6f2125f2a5..8aa4ecde5f 100644 --- a/doc/src/sgml/high-availability.sgml +++ b/doc/src/sgml/high-availability.sgml @@ -1,4 +1,4 @@ - + High Availability, Load Balancing, and Replication @@ -161,21 +161,21 @@ protocol to make nodes agree on a serializable transactional order. - Trigger-Based Master-Slave Replication + Trigger-Based Master-Standby Replication - 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. 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. @@ -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 ( @@ -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 — 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 random(). @@ -291,7 +291,7 @@ protocol to make nodes agree on a serializable transactional order. Shared Disk Failover File System Replication Hot/Warm Standby Using PITR - Trigger-Based Master-Slave Replication + Trigger-Based Master-Standby Replication Statement-Based Replication Middleware Asynchronous Multimaster Replication Synchronous Multimaster Replication @@ -378,7 +378,7 @@ protocol to make nodes agree on a serializable transactional order. - Slaves accept read-only queries + Standby accept read-only queries Hot only @@ -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. diff --git a/doc/src/sgml/protocol.sgml b/doc/src/sgml/protocol.sgml index b88833c8ee..dc165f7253 100644 --- a/doc/src/sgml/protocol.sgml +++ b/doc/src/sgml/protocol.sgml @@ -1,4 +1,4 @@ - + Frontend/Backend Protocol @@ -1315,7 +1315,7 @@ The commands accepted in walsender mode are: 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. @@ -1326,7 +1326,7 @@ The commands accepted in walsender mode are: - Current TimelineID. Also useful to check that the slave is + Current TimelineID. Also useful to check that the standby is consistent with the master. diff --git a/doc/src/sgml/release-9.0.sgml b/doc/src/sgml/release-9.0.sgml index bec6a00084..8777a2c904 100644 --- a/doc/src/sgml/release-9.0.sgml +++ b/doc/src/sgml/release-9.0.sgml @@ -1,4 +1,4 @@ - + Release 9.0 @@ -398,7 +398,7 @@ recovery_connections -> hot_standby Previously 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 postgresql.conf + standby with very little delay. There are new postgresql.conf and recovery.conf settings to enable this feature, as well as extensive documentation. diff --git a/doc/src/sgml/release-alpha.sgml b/doc/src/sgml/release-alpha.sgml index 3eb9f6bac6..9cc7e8d59f 100644 --- a/doc/src/sgml/release-alpha.sgml +++ b/doc/src/sgml/release-alpha.sgml @@ -1,4 +1,4 @@ - + Release 9.0alpha4 @@ -126,7 +126,7 @@ 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. @@ -552,7 +552,7 @@ 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. -- 2.40.0