> 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 _______________________________________________ Pgpool-hackers mailing list [email protected] http://pgfoundry.org/mailman/listinfo/pgpool-hackers
