On 5/3/2005 3:55 PM, Julian Scarfe wrote:

> From: "Jan Wieck" <JanWieck at Yahoo.com>
> 
>>I think you realize by now that this is a functionality that falls into the 
>>category of network monitoring.
> 
> Well, yes and no, Jan.
> 
> One of the features of Slony that has always appealed is the separation of 
> replication from failover functionality.  I wouldn't want to change that for 
> the world, and I don't want you to build anything into Slony that does 
> network monitoring.
> 
> But I do think that it's still a legitimate question to ask: given two 
> nodes, one of which used to be the provider, and the other of which used to 
> be a receiver but has become provider by the execution of a failover 
> command, can I tell that has happened by connecting only to the original 
> provider?

Absolutely legitimate, but the answer is no. There is the chance that 
the old provider may not have been reachable when the failover happened. 
This could be for a gazillion of reasons, network cable, postmaster 
down, system down, who knows. Without telling some network component 
like a switch or router "don't let anyone reach it any more" it will not 
know what happened when it comes back up and someone connects.

> 
>> When your "network monitor" detects that either the client or node 2 can't 
>> talk to node 1 any more, "it" has to make sure that they will not do so 
>> all of the sudden (reconfigure switches or iptables), fire the slonik 
>> script telling node 2 to take over, and reconfigure something like pgpool 
>> to redirect the client to the new master.
> 
> I think you're making an assumption that it is desirable or even possible to 
> do that in one process.  What I'm trying to do is separate the middle 
> fire-the-failover-script step from the configuration of an interface like 
> pg_pool.  When the cluster is functioning normally, the interface can work 
> out the master-slave configuration for itself and so can be stateless, in 
> the sense of not having to read a resource that says "the master is now this 
> one". I'd like it to be able to do that after failover too.

Whatever fires the failover script will also have to fire the 
reconfigure connection pool part. I rather assume or imagine a 
connection pool that runs as a virtual server. As long as the pool 
always knows which is the current master and what are the currently 
available replicas, all the client has to do is to connect to either the 
"write-pool" or the "readonly-pool" and it will get a connection.

This is not stateless, since the pool knows what's the current config. 
But your clients won't have to worry about it.


Jan

-- 
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck at Yahoo.com #