Hi, I've pushed most of the changes.
On 2020-06-16 18:59:25 -0400, David Steele wrote: > On 6/16/20 6:27 PM, Andres Freund wrote: > > On 2020-06-16 17:14:57 -0400, David Steele wrote: > > > On 6/15/20 2:22 PM, Andres Freund wrote: > > > > > > 0008: docs: WIP multi-master rephrasing. > > > > I like neither the new nor the old language much. I'd welcome input. > > > > > > Why not multi-primary? > > > > My understanding of primary is that there really can't be two things > > that are primary in relation to each other. > > Well, I think the same is true for multi-master and that's pretty common. > > > active/active is probably > > the most common term in use besides multi-master. > > Works for me and can always be updated later if we come up with something > better. At least active-active will be easier to search for. What do you think about the attached? Greetings, Andres Freund
>From 254c1f45beb8e9dee840a497d5c040b00015a8f3 Mon Sep 17 00:00:00 2001 From: Andres Freund <and...@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.x7lch5n6kcjq4...@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 — 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
