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.
+ 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?
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
Why do you remove the sentence about the extra option available to the
user here, about the traditional primary-standby setup?
--
Michael