From 254c1f45beb8e9dee840a497d5c040b00015a8f3 Mon Sep 17 00:00:00 2001
From: Andres Freund <andres@anarazel.de>
Date: Mon, 15 Jun 2020 10:39:15 -0700
Subject: [PATCH] docs: use active-active instead of multi-master replication.

Author: Andres Freund
Reviewed-By: David Steele
Discussion: https://postgr.es/m/20200615182235.x7lch5n6kcjq4aue@alap3.anarazel.de
---
 doc/src/sgml/high-availability.sgml | 34 +++++++++++++++--------------
 1 file changed, 18 insertions(+), 16 deletions(-)

diff --git a/doc/src/sgml/high-availability.sgml b/doc/src/sgml/high-availability.sgml
index 6a9184f314e..2e090419f18 100644
--- a/doc/src/sgml/high-availability.sgml
+++ b/doc/src/sgml/high-availability.sgml
@@ -38,12 +38,14 @@
  <para>
   Some solutions deal with synchronization by allowing only one
   server to modify the data.  Servers that can modify data are
-  called read/write, <firstterm>master</firstterm> or <firstterm>primary</firstterm> servers.
-  Servers that track changes in the master are called <firstterm>standby</firstterm>
-  or <firstterm>secondary</firstterm> servers. A standby server that cannot be connected
-  to until it is promoted to a master server is called a <firstterm>warm
-  standby</firstterm> server, and one that can accept connections and serves read-only
-  queries is called a <firstterm>hot standby</firstterm> server.
+  called read/write, <firstterm>primary</firstterm>,
+  <firstterm>active</firstterm> (or <firstterm>master</firstterm>) servers.
+  Servers that track changes in the primary are called
+  <firstterm>standby</firstterm> or <firstterm>secondary</firstterm> servers.
+  A standby server that cannot be connected to until it is promoted to a
+  primary server is called a <firstterm>warm standby</firstterm> server, and
+  one that can accept connections and serves read-only queries is called a
+  <firstterm>hot standby</firstterm> server.
  </para>
 
  <para>
@@ -177,14 +179,14 @@ protocol to make nodes agree on a serializable transactional order.
   </varlistentry>
 
   <varlistentry>
-   <term>Trigger-Based Master-Standby Replication</term>
+   <term>Trigger-Based Primary-Standby Replication</term>
    <listitem>
 
     <para>
-     A master-standby replication setup sends all data modification
-     queries to the master server.  The master server asynchronously
+     A primary-standby replication setup sends all data modification
+     queries to the primary server.  The primary server asynchronously
      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 primary server is running.  The
      standby server is ideal for data warehouse queries.
     </para>
 
@@ -233,14 +235,14 @@ protocol to make nodes agree on a serializable transactional order.
   </varlistentry>
 
   <varlistentry>
-   <term>Asynchronous Multimaster Replication</term>
+   <term>Asynchronous Active-Active Replication</term>
    <listitem>
 
     <para>
      For servers that are not regularly connected or have slow
      communication links, like laptops or
      remote servers, keeping data consistent among servers is a
-     challenge.  Using asynchronous multimaster replication, each
+     challenge.  Using asynchronous active-active replication, each
      server works independently, and periodically communicates with
      the other servers to identify conflicting transactions.  The
      conflicts can be resolved by users or conflict resolution rules.
@@ -250,17 +252,17 @@ protocol to make nodes agree on a serializable transactional order.
   </varlistentry>
 
   <varlistentry>
-   <term>Synchronous Multimaster Replication</term>
+   <term>Synchronous Active-Active Replication</term>
    <listitem>
 
     <para>
-     In synchronous multimaster replication, each server can accept
+     In synchronous active-active replication, each server can accept
      write requests, and modified data is transmitted from the
      original server to every other server before each transaction
      commits.  Heavy write activity can cause excessive locking and
      commit delays, leading to poor performance.  Read requests can
      be sent to any server.  Some implementations use shared disk
-     to reduce the communication overhead.  Synchronous multimaster
+     to reduce the communication overhead.  Synchronous active-active
      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 primary and
@@ -351,7 +353,7 @@ protocol to make nodes agree on a serializable transactional order.
     </row>
 
     <row>
-     <entry>Allows multiple master servers</entry>
+     <entry>Allows multiple primary servers</entry>
      <entry align="center"></entry>
      <entry align="center"></entry>
      <entry align="center"></entry>
-- 
2.25.0.114.g5b0ca878e0