On Sat, Sep 12, 2020 at 3:46 AM Michael Paquier <michael@paquier.xyz> wrote:
On Fri, Sep 11, 2020 at 07:16:43PM -0400, Robert Treat wrote: > A recent discussion on slack prompted me to read through the > high-availability section of the docs, turning in to some suggested > changes that hopefully clarify how the various replication options > work (specifically around logical and trigger-based solutions). A > proposed patch is attached, lmk if you have questions.
A portion of what you are suggesting here is in line with 9e101cf, which looks like a good thing. Most of the changes look like improvements to me, and here are some comments.
+1.
+ queries to a designated primary server. Operating on a per-tablebasis, + the primary server sends data changes (typically) asynchronously to the + replica node(s). Replica nodes can answer queries while the primary is Could it be better to use "one or more replica clusters" here?
In particular, why is the primary a "server" and the replica a "node"? That caught my eye for inconsistency -- but changing node to cluster will be equally inconsistent, just in a different way. Why not just call them both servers?
