> Hi,
>
> I'm currently writing some inhouse DR instructions for a database using
> slony.  I'm currently writing these aimed at the altperl scripts for
> maintaining slony.  I've noticed that some of the scripts expect the
> arguements in different orders.  In particular move_set.pl and
> failover.pl.  Any chance of having these consistent?

I happily haven't had call to run the failover one; making the arguments
more consistent there is an excellent idea.

I haven't heard any hint of anyone having any 'metascripts' that use these
scripts, so nothing prevents improving the rationality of the arguments. 
Please point out any places where consistency could be improved.

I have generated some inhouse instructions that live alongside the
scripts; I could easily see it being useful to try to turn this into
boilerplate that would be generally usable.  If you contributed some
(suitably redacted) of your instructions, that could surely be helpful to
this.

We have noticed something today of this sort in terms of, oh, call it
"anti-documentation" vis-a-vis node numbering.  I set up a whole series of
nodes on a set of 4 servers for different replication instances.  I
numbered things 1 = master, 2=main slave, 3=server "db3", 4=server at
another site.  Nodes #3 and #4 are always pointing to two particular
servers.  Unfortunately, #1 and #2 aren't consistent that way.

In retrospect, since internal server numbers for these four servers are
003, 004, 005, and 501, it would likely be most intuitive to have nodes 3,
4, 5, and 501, which , while not consecutive, will be easy to guess right
about.

I have to kick myself on that a bit because I remember rueing someone
else's choice, with ERServe, the same sort of scheme where, for each set
of nodes:
 1 = the master node,
 2 = the first slave we set up,
 3 = the second slave we set up,
and so forth, which were anything but easy to intuit about.

It's no big deal for people that just have 2 nodes.  But eventually, we're
likely to add more to the 4.  And for the node numbering to not be pretty
coherent lies madness.