replication wordsmithing / clarifications

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

replication wordsmithing / clarifications

Robert Treat-3
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

replication-wordsmithing.patch (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: replication wordsmithing / clarifications

Michael Paquier-2
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

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: replication wordsmithing / clarifications

Magnus Hagander-2


On Sat, Sep 12, 2020 at 3:46 AM Michael Paquier <[hidden email]> 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?

--
Reply | Threaded
Open this post in threaded view
|

Re: replication wordsmithing / clarifications

Robert Treat-3
In reply to this post by Michael Paquier-2
On Fri, Sep 11, 2020 at 9:46 PM Michael Paquier <[hidden email]> 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


Reply | Threaded
Open this post in threaded view
|

Re: replication wordsmithing / clarifications

Michael Paquier-2
In reply to this post by Magnus Hagander-2
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

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: replication wordsmithing / clarifications

Michael Paquier-2
In reply to this post by Robert Treat-3
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

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: replication wordsmithing / clarifications

Robert Treat-3
On Mon, Sep 14, 2020 at 4:11 AM Michael Paquier <[hidden email]> 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


Reply | Threaded
Open this post in threaded view
|

Re: replication wordsmithing / clarifications

Michael Paquier-2
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

signature.asc (849 bytes) Download Attachment