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 :-)
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. 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. >>> 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? 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. Regards -- Gilles Darold http://dalibo.com - http://dalibo.org _______________________________________________ Pgpool-hackers mailing list [email protected] http://pgfoundry.org/mailman/listinfo/pgpool-hackers
