-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Le 25/01/2011 01:06, Tatsuo Ishii a écrit : >> 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?
Erf, sorry, there's no public log about that discussion because it stud actually on IRC... >>> 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 - -- 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/ iEYEARECAAYFAk0+iKEACgkQXu9L1HbaT6JWwACffY8kAd5rxPU1IXBsA6Yrf6PF fvoAoN/talpRlSw2INWxsYN3yGHjMcIR =F+LI -----END PGP SIGNATURE----- _______________________________________________ Pgpool-hackers mailing list [email protected] http://pgfoundry.org/mailman/listinfo/pgpool-hackers
