Jan Wieck said:
>
> The communication channels are "event" tables. The node daemons
> use  listen and notify to send messages from on to another.
> Messages are only exchanged over this when the replication cluster
> configuration is changed or every 10 seconds to tell "new
> replication data has  accumulated, come and get it". So I think
> the listen/notify protocol suits well for that.
>
> Some of the functionality happening on an event is already put
> into  stored procedures, and the replication engine as well as the
> (to be) admin tools just call those. But that doesn't mean that
> using psql will  do the job. There are certain operations that
> need to be
> initiated (the  corresponding SP called) on a particular node, not
> just on any available one. Also, these stored procedures take
> arguments, most of which are just the ID numbers of configuration
> objects. Not the ideal user interface.

So some of the regular tasks can be performed from any of the nodes
and some need to be done from a specific node. But if connected to the
right node, they can all be done through sql and the management tool
doesn't need shell access on the nodes. Right?


> There must be some external tools. And to be integrated into any
> automated failover system, it needs to be commandline. So that one
> is a given.

Would a database function that is called from the commandline like
sudo -u postgres psql -c 'select "_MyCluster".useMaster(2,3,4);'
qualify for that?

Jochem





Sun, 7 Mar 2004 20:55:16 +0100 (CET)
"Jochem van Dieten" <jochemd@oli.tudelft.nl>
Re: Slony-I makes progress
Jochem van Dieten wrote:

> Jan Wieck said:
>>
>> The communication channels are "event" tables. The node daemons
>> use  listen and notify to send messages from on to another.
>> Messages are only exchanged over this when the replication cluster
>> configuration is changed or every 10 seconds to tell "new
>> replication data has  accumulated, come and get it". So I think
>> the listen/notify protocol suits well for that.
>>
>> Some of the functionality happening on an event is already put
>> into  stored procedures, and the replication engine as well as the
>> (to be) admin tools just call those. But that doesn't mean that
>> using psql will  do the job. There are certain operations that
>> need to be
>> initiated (the  corresponding SP called) on a particular node, not
>> just on any available one. Also, these stored procedures take
>> arguments, most of which are just the ID numbers of configuration
>> objects. Not the ideal user interface.
> 
> So some of the regular tasks can be performed from any of the nodes
> and some need to be done from a specific node. But if connected to the
> right node, they can all be done through sql and the management tool
> doesn't need shell access on the nodes. Right?

No action so far needs shell acceess to any specific system. Everything 
works through regular DB connections. It means however that the admin 
tools will have postmaster port access to "every" node, from where they 
are run. I don't think that this is an unreasonable requirement for the 
DBA workstation in a datacenter.

> 
> 
>> There must be some external tools. And to be integrated into any
>> automated failover system, it needs to be commandline. So that one
>> is a given.
> 
> Would a database function that is called from the commandline like
> sudo -u postgres psql -c 'select "_MyCluster".useMaster(2,3,4);'
> qualify for that?

That has no advantage over

     sudo -u postgres slony_admtool -f MyCluster_emeergency_plan_A

Especially because psql does not allow multiple simultaneous DB 
connections and has no control language for procedures.




Jan

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


Sun, 07 Mar 2004 18:48:37 -0500
Jan Wieck <JanWieck@Yahoo.com>
Re: Slony-I makes progress