Re: Support for N synchronous standby servers - take 2

Reply to multiple member.

> Hm. This is not much helpful in the case we especially mentioned
> upthread at some point with 2 data centers, first one has the master
> and a sync standby, and second one has a set of standbys. We need to
> be sure that the standby in DC1 acknowledges all the time, and we
> would only need to wait for one or more of them in DC2. I still
> believe that this is the main use case for this feature to ensure a
> proper failover without data loss if one data center blows away with a
> meteorite.

Yes, I think so too.
In such case, the idea I posted yesterday could handle by setting the
followings;
* s_r_method = 'quorum'
* s_s_names = 'tokyo, seattle'
* s_s_nums = 2
* application_name of the first standby, which is in DC1, is 'tokyo',
and application_name of other standbys, which are in DC2, is
'seattle'.

> And I guess that they manage standby nodes using a system catalog
> then, being able to change the state of a node from async to sync with
> something at SQL level? Is that right?

I think that's right.

>
> If we go that path, I think that we still would need an extra
> parameter to control the number of nodes that need to be taken from
> the set defined in s_s_names whichever of quorum or priority is used.
> Let's not forget that in the current configuration the first node
> listed in s_s_names and *connected* to the master will be used to
> acknowledge the commit.

Yeah, such parameter is needed. I've forgotten to consider that.

>
>
> Would it be better to just use a simple language instead of 3 different
> parameters?
>
> s_s_names = 2[X,Y,Z] # 2 priority
> s_s_names = 1(A,B,C) # 1 quorum
> s_s_names = R,S,T # default behavior: 1 priorty?

I think that this means that we have choose dedicated language
approach instead of JSON format approach.
If we want to set multi sync replication more complexly, we would not
have no choice other than improvement of dedicated language.

Regards,

--
Masahiko Sawada