Re: Standalone synchronous master

On Sat, Jan 11, 2014 at 9:41 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> On Sat, Jan 11, 2014 at 01:29:23PM +0530, Amit Kapila wrote:
>> Okay, this is one way of providing this new mode, others could be:
>>
>> a.
>> Have just one GUC sync_standalone_mode = true|false and make
>> this as PGC_POSTMASTER parameter, so that user is only
>> allowed to set this mode at startup. Even if we don't want it as
>> Postmaster parameter, we can mention to users that they can
>> change this parameter only before server reaches current situation.
>> I understand that without any alarm or some other way, it is difficult
>> for user to know and change it, but I think in that case he should
>> set it before server startup.
>>
>> b.
>> On above lines, instead of boolean parameter, provide a parameter
>> similar to current one such as available_synchronous_standby_names,
>> setting of this should follow what I said in point a. The benefit in this
>> as compare to 'a' is that it appears to be more like what we currently have.
>>
>> I think if we try to solve this problem by providing a way so that user
>> can change it at runtime or when the problem actually occurred, it can
>> make the UI more complex and difficult for us to provide a way so that
>> user can be alerted on such situation. We can keep our options open
>> so that if tomorrow, we can find any reasonable way, then we can
>> provide it to user a mechanism for changing this at runtime, but I don't
>> think it is stopping us from providing a way with which user can get the
>> benefit of this mode by providing start time parameter.
>
> I am not sure how this would work. Right now we wait for one of the
> synchronous_standby_names servers to verify the writes. We need some
> way of telling the system how long to wait before continuing in degraded
> mode. Without a timeout and admin notification, it doesn't seem much
> better than our async mode, which is what many people were complaining
> about.

It is better than async mode in a way such that in async mode it never
waits for commits to be written to standby, but in this new mode it will
do so unless it is not possible (all sync standby's goes down).
Can't we use existing wal_sender_timeout, or even if user expects a
different timeout because for this new mode, he expects master to wait
more before it start operating like standalone sync master, we can provide
a new parameter.

With this the definition of new mode is to provide maximum
availability.

We can define the behavior in this new mode as:
a. It will operate like current synchronous master till one of the standby
mentioned in available_synchronous_standby_names is available.
b. If none is available, then it will start operating link current async
master, which means that if any async standby is configured, then
it will start sending WAL to that standby asynchronously, else if none
is configured, it will start operating in a standalone master.
c. We can even provide a new parameter replication_mode here
(non persistent), which will tell to user that master has switched
its mode, this can be made available by view. Update the value of
parameter when server switches to new mode.
d. When one of the standby mentioned in
available_synchronous_standby_names comes back and able to resolve
all WAL difference, then it will again switch back to sync mode, where it
will write to that standby before Commit finishes. After switch, it will
update the replication_mode parameter.

Now I think with above definition and behavior, it can switch to new mode
and will be able to provide information if user wants it by using view.

In above behaviour, the tricky part would be point 'd' where it has to switch
back to sync mode when one of the sync standby become available, but I
think we can workout design for that if you are positive about the above
definition and behaviour as defined by 4 points.

With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com