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