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

[Jehan-Guillaume (ioguix) de Rorthais]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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.

Mh, considering this situation,  I would not add another dwitch control or
parameter to pgpool, but instead leave this task to the admin script giving him
the possibility to degenerate the slaves when he wants before/after/never the
pcp_promote_node.

> 
>>> 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.
> 
> BTW how can we determine the promoting standby has finished the
> reconvery and become ok to accept write queries?

That's exactly my point about using "recovery_end_command" from PostgreSQL itself.
Only PostgreSQL has this information clearly. So instead of messing from pgpool
which can only have mechanism to ask or guess when the new master is available,
I would rather make PostgreSQL tell pgpool he is ready.

>> Using this existing mechanism from postgresql itself would avoid some new code
>> block in pgpool, delay, check to see if the new master is up or not, etc
>>
>>>
>>> I've played some time with that patch and it works pretty well for me.
>>>
>>> Well before going further I need to know if this is something useful
>>> that can be applied to PgPool? I also need help for testing under other
>>> modes than streaming replication.
>>>
>>> Thanks for your comments.
>>>
>>> Best regards,
>>>
>>
>>
>> - -- 
>> Jehan-Guillaume de Rorthais
>> DBA
>> http://www.dalibo.com
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.10 (GNU/Linux)
>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>>
>> iEYEARECAAYFAk09eboACgkQXu9L1HbaT6JvwACcDSNQ1c21Vmci5IOgaMrSQDir
>> x+IAoNPxUu79p98UWBe+pJFqcr9syxtZ
>> =esw+
>> -----END PGP SIGNATURE-----
>> _______________________________________________
>> Pgpool-hackers mailing list
>> Pgpool-hackers at pgfoundry.org
>> http://pgfoundry.org/mailman/listinfo/pgpool-hackers


- -- 
Jehan-Guillaume de Rorthais
DBA
http://www.dalibo.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk0927UACgkQXu9L1HbaT6IIDwCg6OvMC9RzrE2PinTBMUH9xqwn
tDwAoOgoLwLDp/NWl2MwR8nTJwt6uzmx
=fpZh
-----END PGP SIGNATURE-----