Re: replication wordsmithing / clarifications

Поиск
Список
Период
Сортировка
От Robert Treat
Тема Re: replication wordsmithing / clarifications
Дата
Msg-id CAJSLCQ0=dq1e8VifMntyAwo_rvE36y-UG+rcO622oNKBUherCQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: replication wordsmithing / clarifications  (Michael Paquier <michael@paquier.xyz>)
Ответы Re: replication wordsmithing / clarifications
Список pgsql-docs
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



В списке pgsql-docs по дате отправления:

Предыдущее
От: Magnus Hagander
Дата:
Сообщение: Re: replication wordsmithing / clarifications
Следующее
От: PG Doc comments form
Дата:
Сообщение: target_role definition clarification