[Pgpool-hackers] Promoting any node as master with SR slaves follow

[Tatsuo Ishii]

> Hi,
> 
> Le 24/01/2011 15:38, Tatsuo Ishii a écrit :
>>> Le 20/01/2011 20:15, Gilles Darold a écrit :
>>>> Hi,
>>>>
>>>> [...]
>>>>
>>>> All this make me do some work on PgPool source code as I think it may
>>>> handle that easily. The patch do the following:
>>>>
>>>> Add a PCP command to promote any node in the pgpool line as the new
>>>> master : pcp_promote_node
>>>> Add a follow master configuration option to call an external command
>>>> when the failover is over.
>>>>
>>>> So that if I run :
>>>>
>>>>     pcp_promote_node 10 192.168.1.11 9898 postgres postgres 3
>>>>
>>>> Node 3 is promoted as master and all other nodes are degenerated.
>>> great. +1
>> Thinking a little bit more, there seems to be an use case where it's
>> not a good idea. Consider a heavyly read system rarely updated. In a
>> case data is not so often updated, maybe once a day. Nodes that were
>> not promoted do not have old data until daily updation occurs. So
>> there's no need to degenerate those nodes until that. If you do not
>> like this, you could always use "delay_threthold". I admit that
>> there's a case immediate degeration is appropreate. So we may need a
>> switch to control the behavior.
> The way I've coded that is very simple : automatic slave degeneration
> and recovery over the new master is done only if you have filled the
> "follow_master_command" configuration directive. In the other case
> nothing is done than the failover and you have all your time to manually
> handle slaves detach and recovery stage once the update happens :-)

I'm not sure your implementation details because you did not show us
your patches.

> Using a threshold value can be used to delay degeneration during a
> certain laps of time, but I'm not sure that this is something valuable.
> When a cluster is broken what we may want is to be back asap in a stable
> situation and not waiting an hypothetical update on the new master.

That is *one* of the use cases.

> The worse situation with this delay_threshold is when a failover happen
> and wait some minutes/hours the update query. In this laps of time the
> fresh new master crash so that a new failover is done on an other node, etc.

Then just another standby is prmoted to primary. I see no problem here?

>>>> When the failover is ended PgPool fork a child to execute the command
>>>> given in the follow_master_command successively for each node
>>>> degenerated. The follow master command is simply a call to the
>>>> pcp_recovery_node.
>>> IIRC, we talked a bit about that together a week or two ago.
>>> it seems to me it would be cleaner and simpler to use the parameter
>>> "recovery_end_command" from the postgresql recovery.conf file to send the
>>> command follow_master_command to the pgpool service as soon as the new master is
>>> effectively up and ready.
>> I'll catch up the discussion.

I couldn't find discussion on "recovery_end_command". Could you please
give me a pointer?

>> BTW how can we determine the promoting standby has finished the
>> reconvery and become ok to accept write queries?
> 
> I'm not agree jehan-guillaume, I think that the context can be fully and
> better handled with PgPool. PostgreSQL on a standby node doesn't  have
> any idea of who are the others standby nodes and then how it can
> advertised them to follow ? PgPool always maintained the list and the
> states of the standby nodes.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp