From: Michael Paquier Date: Fri, 2 Oct 2020 01:36:35 +0000 (+0900) Subject: doc: Improve some documentation about HA and replication X-Git-Tag: REL_14_BETA1~1561 X-Git-Url: http://git.postgresql.org/gitweb/?a=commitdiff_plain;h=8550cbd0bae7c3004034351cb3447b51a552e56c;p=postgresql.git doc: Improve some documentation about HA and replication This clarifies some wording in the description of the options available as replication solutions. While on it, this replaces some instances of "master" with "primary", for consistency with recent changes like 9e101cf. Author: Robert Treat Reviewed-by: Magnus Hagander, Michael Paquier Discussion: https://postgr.es/m/CAJSLCQ2TPaK_K8raofCamrqELCxY-H6mJrpDNRzc-LKpPY7c+g@mail.gmail.com --- diff --git a/doc/src/sgml/high-availability.sgml b/doc/src/sgml/high-availability.sgml index 42f01c515f9..86da84fce70 100644 --- a/doc/src/sgml/high-availability.sgml +++ b/doc/src/sgml/high-availability.sgml @@ -39,9 +39,9 @@ Some solutions deal with synchronization by allowing only one server to modify the data. Servers that can modify data are called read/write, master or primary servers. - Servers that track changes in the master are called standby + Servers that track changes in the primary are called standby or secondary servers. A standby server that cannot be connected - to until it is promoted to a master server is called a warm + to until it is promoted to a primary server is called a warm standby server, and one that can accept connections and serves read-only queries is called a hot standby server. @@ -165,10 +165,10 @@ protocol to make nodes agree on a serializable transactional order. Logical replication allows a database server to send a stream of data modifications to another server. PostgreSQL logical replication constructs a stream of logical data modifications - from the WAL. Logical replication allows the data changes from - individual tables to be replicated. Logical replication doesn't require - a particular server to be designated as a primary or a replica but allows - data to flow in multiple directions. For more information on logical + from the WAL. Logical replication allows replication of data changes on + a per-table basis. In addition, a server that is publishing its own + changes can also subscribe to changes from another server, allowing data + to flow in multiple directions. For more information on logical replication, see . Through the logical decoding interface (), third-party extensions can also provide similar functionality. @@ -177,22 +177,24 @@ protocol to make nodes agree on a serializable transactional order. - Trigger-Based Master-Standby Replication + Trigger-Based Primary-Standby Replication - A master-standby replication setup sends all data modification - queries to the master server. The master server asynchronously - sends data changes to the standby server. The standby can answer - read-only queries while the master server is running. The - standby server is ideal for data warehouse queries. + A trigger-based replication setup typically funnels data modification + queries to a designated primary server. Operating on a per-table basis, + the primary server sends data changes (typically) asynchronously to the + standby servers. Standby servers can answer queries while the primary is + running, and may allow some local data changes or write activity. This + form of replication is often used for offloading large analytical or data + warehouse queries. - Slony-I is an example of this type of replication, with per-table - granularity, and support for multiple standby servers. Because it - updates the standby server asynchronously (in batches), there is - possible data loss during fail over. + Slony-I is an example of this type of + replication, with per-table granularity, and support for multiple standby + servers. Because it updates the standby server asynchronously (in + batches), there is possible data loss during fail over. @@ -215,14 +217,10 @@ protocol to make nodes agree on a serializable transactional order. random(), CURRENT_TIMESTAMP, and sequences can have different values on different servers. This is because each server operates independently, and because - SQL queries are broadcast (and not actual modified rows). If + SQL queries are broadcast rather than actual data changes. If 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 primary-standby setup, i.e., data modification - queries are sent only to the primary and are propagated to the - standby servers via primary-standby replication, not by the replication - middleware. Care must also be taken that all + must determine such values from a single source and then use those + values in write queries. Care must also be taken that all transactions either commit or abort on all servers, perhaps using two-phase commit ( and ). @@ -351,7 +349,7 @@ protocol to make nodes agree on a serializable transactional order. - Allows multiple master servers + Allows multiple primary servers