Re: Support for N synchronous standby servers - take 2

Поиск
Список
Период
Сортировка
От Sawada Masahiko
Тема Re: Support for N synchronous standby servers - take 2
Дата
Msg-id CAD21AoCSajf_p2GV4veg5k5cBr_=zxJzCLU=zZGrZHWgF2TX6g@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Support for N synchronous standby servers - take 2  (Michael Paquier <michael.paquier@gmail.com>)
Ответы Re: Support for N synchronous standby servers - take 2  (Michael Paquier <michael.paquier@gmail.com>)
Список pgsql-hackers
On Tue, Jul 21, 2015 at 3:50 PM, Michael Paquier
<michael.paquier@gmail.com> wrote:
> On Mon, Jul 20, 2015 at 9:59 PM, Beena Emerson <memissemerson@gmail.com> wrote:
>> Simon Riggs wrote:
>>
>>> The choice between formats is not
>>> solely predicated on whether we have multi-line support.
>>
>>> I still think writing down some actual use cases would help bring the
>>> discussion to a conclusion. Inventing a general facility is hard without
>>> some clear goals about what we need to support.
>>
>> We need to at least support the following:
>> - Grouping: Specify of standbys along with the minimum number of commits
>> required from the group.
>> - Group Type: Groups can either be priority or quorum group.
>
> As far as I understood at the lowest level a group is just an alias
> for a list of nodes, quorum or priority are properties that can be
> applied to a group of nodes when this group is used in the expression
> to define what means synchronous commit.
>
>> - Group names: to simplify status reporting
>> - Nesting: At least 2 levels of nesting
>
> If I am following correctly, at the first level there is the
> definition of the top level objects, like groups and sync expression.
>

The grouping and using same application_name different server is similar.
How does the same application_name different server work?

>> Using JSON, sync rep parameter to replicate in 2 different clusters could be
>> written as:
>>
>>    {"remotes":
>>         {"quorum": 2,
>>          "servers": [{"london":
>>             {"priority": 2,
>>              "servers": ["lndn1", "lndn2", "lndn3"]
>>             }}
>>             ,
>>               {"nyc":
>>             {"priority": 1,
>>              "servers": ["ny1", "ny2"]
>>             }}
>>           ]
>>         }
>>     }
>> The same parameter in the new language (as suggested above) could be written
>> as:
>>  'remotes: 2(london: 1[lndn1, lndn2, lndn3], nyc: 1[ny1, ny2])'
>
> OK, there is a typo. That's actually 2(london: 2[lndn1, lndn2, lndn3],
> nyc: 1[ny1, ny2]) in your grammar. Honestly, if we want group aliases,
> I think that JSON makes the most sense. One of the advantage of a
> group is that you can use it in several places in the blob and set
> different properties into it, hence we should be able to define a
> group out of the sync expression.
> Hence I would think that something like that makes more sense:
> {
>         "sync_standby_names":
>         {
>                 "quorum":2,
>                 "nodes":
>                 [
>                         {"priority":1,"group":"cluster1"},
>                         {"quorum":2,"nodes":["node1","node2","node3"]}
>                 ]
>         },
>         "groups":
>         {
>                 "cluster1":["node11","node12","node13"],
>                 "cluster2":["node21","node22","node23"]
>         }
> }
>
>> Also, I was thinking the name of the main group could be optional.
>> Internally, it can be given the name 'default group' or 'main group' for
>> status reporting.
>>
>> The above could also be written as:
>>  '2(london: 2[lndn1, lndn2, lndn3], nyc: 1[ny1, ny2])'
>>
>> backward compatible:
>> In JSON, while validating we may have to check if it starts with '{' to go
>
> Something worth noticing, application_name can begin with "{".
>
>> for JSON parsing else proceed with the current method.
>
>> A,B,C => 1[A,B,C]. This can be added in the new parser code.
>
> This makes sense. We could do the same for JSON-based format as well
> by reusing the in-memory structure used to deparse the blob when the
> former grammar is used as well.

If I validate s_s_name JSON syntax, I will definitely use JSONB,
rather than JSON.
Because JSONB has some useful operation functions for adding node,
deleting node to s_s_name today.
But the down side of using JSONB for s_s_name is that it could switch
in key name order place.(and remove duplicate key)
For example in the syntax Michael suggested,


* JSON (just casting JSON)                                 json
------------------------------------------------------------------------{
                     +        "sync_standby_names":                                         +        {
                                          +                "quorum":2,                                           +
         "nodes":                                              +                [
             +                        {"priority":1,"group":"cluster1"},            +
{"quorum":2,"nodes":["node1","node2","node3"]}+               ]                                                     +
    },                                                            +        "groups":
                +        {                                                             +
"cluster1":["node11","node12","node13"],             +                "cluster2":["node21","node22","node23"]
   +        }                                                             +}
 

* JSONB (using jsonb_pretty)            jsonb_pretty
--------------------------------------{                                   +    "groups": {                     +
"cluster1":[               +            "node11",               +            "node12",               +
"node13"               +        ],                          +        "cluster2": [               +            "node21",
             +            "node22",               +            "node23"                +        ]
   +    },                              +    "sync_standby_names": {         +        "nodes": [                  +
      {                       +                "group": "cluster1",+                "priority": 1       +            },
                    +            {                       +                "nodes": [          +
"node1",       +                    "node2",        +                    "node3"         +                ],
     +                "quorum": 2         +            }                       +        ],                          +
    "quorum": 2                 +    }                               +}
 

"group" and "sync_standby_names" has been switched place. I'm not sure
it's good for the users.

Regards,

--
Masahiko Sawada



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

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: pg_basebackup and replication slots
Следующее
От: Andres Freund
Дата:
Сообщение: Re: LWLock deadlock and gdb advice