Обсуждение: replication wordsmithing / clarifications

Howdy folks,

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.


Robert Treat
https://xzilla.net

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

On Fri, Sep 11, 2020 at 9:46 PM 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.
>
> +     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?
>

maybe "to one or more replicas." or maybe "to one or more replica
targets." I'd avoid the word cluster because you could set it up to
send to multiple databases in the same postgres cluster.

>       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?

If you think about it, this sentence is essentially saying "If you
don't like the downsides of this replication method, you can use an
entirely different replication method." Well sure, you could, but once
you are using a different method, you are no longer using the method
we are trying to describe. In addition, there are several other
systems you could use beyond the suggested one, so suggestion this
specific one felt mis-leading or out of place. And it is not something
we talk about in any of the other sections (after all, every
replication system has trade-offs that might not be acceptable, that's
why we have so many of them).

Robert Treat
https://xzilla.net

On Sat, Sep 12, 2020 at 11:52:11AM +0200, Magnus Hagander wrote:
> 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?

Makes sense.
--
Michael

On Sat, Sep 12, 2020 at 12:40:45PM -0400, Robert Treat wrote:
> maybe "to one or more replicas." or maybe "to one or more replica
> targets." I'd avoid the word cluster because you could set it up to
> send to multiple databases in the same postgres cluster.

Magnus has given a better suggestion: to just use "servers".

> If you think about it, this sentence is essentially saying "If you
> don't like the downsides of this replication method, you can use an
> entirely different replication method." Well sure, you could, but once
> you are using a different method, you are no longer using the method
> we are trying to describe. In addition, there are several other
> systems you could use beyond the suggested one, so suggestion this
> specific one felt mis-leading or out of place. And it is not something
> we talk about in any of the other sections (after all, every
> replication system has trade-offs that might not be acceptable, that's
> why we have so many of them).

OK, I see your point.  Seeing like that, it makes sense.
--
Michael

On Mon, Sep 14, 2020 at 4:11 AM Michael Paquier <michael@paquier.xyz> wrote:
>
> On Sat, Sep 12, 2020 at 12:40:45PM -0400, Robert Treat wrote:
> > maybe "to one or more replicas." or maybe "to one or more replica
> > targets." I'd avoid the word cluster because you could set it up to
> > send to multiple databases in the same postgres cluster.
>
> Magnus has given a better suggestion: to just use "servers".
>

I think I like targets over servers, since it could be a different
server or the same server or even the same database, but happy either
way.

> > If you think about it, this sentence is essentially saying "If you
> > don't like the downsides of this replication method, you can use an
> > entirely different replication method." Well sure, you could, but once
> > you are using a different method, you are no longer using the method
> > we are trying to describe. In addition, there are several other
> > systems you could use beyond the suggested one, so suggestion this
> > specific one felt mis-leading or out of place. And it is not something
> > we talk about in any of the other sections (after all, every
> > replication system has trade-offs that might not be acceptable, that's
> > why we have so many of them).
>
> OK, I see your point.  Seeing like that, it makes sense.

LMK if you'd like an updated patch. Also I wrote this against master,
but could verify it against 13 if folks wanted to backpatch (it might
apply cleanly though)


Robert Treat
https://xzilla.net

On Tue, Sep 15, 2020 at 01:47:07PM -0400, Robert Treat wrote:
> I think I like targets over servers, since it could be a different
> server or the same server or even the same database, but happy either
> way.

I'd say the opposite here: servers over targets.  But that's just one
opinion.

> LMK if you'd like an updated patch. Also I wrote this against master,
> but could verify it against 13 if folks wanted to backpatch (it might
> apply cleanly though)

If you can send a patch, that would be great.  As that's an
improvement, I would go for HEAD only.
--
Michael

On Wed, Sep 16, 2020 at 03:45:32PM +0900, Michael Paquier wrote:
> If you can send a patch, that would be great.  As that's an
> improvement, I would go for HEAD only.

I have gone through this patch set again, and applied most of the
suggested changes on HEAD as of 8550cbd, updating while on it some
extra instances of  "master" to "primary" to be more consistent with
the other changes of this patch.
--
Michael

On Thu, Oct 1, 2020 at 9:39 PM Michael Paquier <michael@paquier.xyz> wrote:
>
> On Wed, Sep 16, 2020 at 03:45:32PM +0900, Michael Paquier wrote:
> > If you can send a patch, that would be great.  As that's an
> > improvement, I would go for HEAD only.
>
> I have gone through this patch set again, and applied most of the
> suggested changes on HEAD as of 8550cbd, updating while on it some
> extra instances of  "master" to "primary" to be more consistent with
> the other changes of this patch.

Merci monsieur!


Robert Treat
https://xzilla.net

On Sun, Oct 04, 2020 at 01:08:56PM -0400, Robert Treat wrote:
> Merci monsieur!

De rien, monsieur.
--
Michael