[Pgpool-hackers] path to follow master after a failover

Tatsuo Ishii ishii at sraoss.co.jp
Wed Feb 23 08:25:41 UTC 2011


Gilles,

It was good to see you in Paris. Now I'm visiting this topic again.

> Le 02/02/2011 00:33, Tatsuo Ishii a écrit :
>>>> - IMO we need finer control over which node should be
>>>>   degenerated. Probably we should have a new flag for each
>>>>   backend something like this:
>>>>
>>>>   backend_option0 = opt_value where opt_value is one of:
>>>>
>>>>   DEGENRATE_IF_NEEDED: degenrate whenever pgpool-II thinks
>>>>   needed. This is same behavior of 3.0 or before.
>>>>
>>>>   NEVER_DEGENRATE: never degerate this node.
>>>>
>>>>   DEGENERATE_IF_NOT_PROMOTED: in the master/slave mode, degenrate the
>>>>   if it's not chosen as NEVER_DEGENRATE: never degerate this nodethe promoting node.
>>>>   (I'm not sure this should apply to slony mode)
>>> Not sure that we really need all of that. In my opinion, we binary use
>>> or not use autorecovery of slaves. What's a reason where we could decide
>>> to not recover a particular slave ?
>> There are at least two use cases:
>>
>> 1) For some reasons (for example, protected by other HA solution such
>>    as heartbeat) we do not want to degenerate the node(probably it's
>>    the master/primary node). We could have yet another switch
>>    "never_degenerate_master_node" or some such, but IMO my proposal is
>>    more general and covers the case.
> 
> In heartbeat solution, the failed node may be dead and the new master
> will not be degenerated as it will be the new master. In all case the
> follow master only affect the standby nodes.

No, I'm talking about pgpool core itself, not follow_master script
patches.

> Maybe we can have an option to not try recovering the failed node and as
> I probably don't saw all the case an option by node allowing or not the
> follow the master can bee added too.
> 
>> 2) Mostly read only huge database which has multiple standbys. The
>>    database is so huge, we don't wan't to recover non promoted
>>    standbys until the maintenance time.
> This is the default case, i-e : no follow.
> 
> 
> Ok, it will be added to the patch. Thanks for your comments.

Ok, I will tackle the new "backend_option" part.  I would like to be
it included in 3.1. I think backend_option is mostly irrevant your
patches anyway, so please revise your patches.

We would want major patches arrived before by the end of Feburary.

> Between March 1 and 8: pgpool-II 3.1.0 beta1 release.
> April 2: pgpool-II 3.1 official release
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp


More information about the Pgpool-hackers mailing list