Anoop Bhat <ABhat at trustwave.com> writes:
> I've got a database that I was replicating manually (without the altperl scripts) for some time but now I'm using the altperl scripts for replication which obviously make things a lot easier.
>
> Four questions from all this.
>
>
>  1.  if I do a slon_kill -config, how can I restart the replication? Can I just a slon_start -config followed by a slonik_subscribe_set -config set1 node2?

You don't need to resubscribe; you merely need to restart the slon
processes.  If there are updates outstanding, they will be carried
over to the subscribers.

There are some ways in which Slony-I is pretty fragile; it's not so
fragile that killing a slon process breaks it :-).

>  2.  I want to get rid of all the previous attempts at
>  replication. Can I simply drop the schemas that were created
>  previously by me on the master?

Slony-I messes (until v2.0) with the internal catalog, so the safe
ways to handle this would include:

 - UNSUBSCRIBE SET
   To remove one subscriber

 - DROP NODE/UNINSTALL NODE
   To clean out one node

>  3.  what is a good way to check the status of the replication to
>  see how much is replicated and or what has been replicated thus
>  far?

There is a view in the Slony-I schema called "sl_status."  Query that
on the origin node, and you'll get a good idea as to how far the
subscribers are behind.

>  4.  I setup all the replication from the slave itself using this as
>  a rough guide
>  http://trac.browsershots.org/wiki/DatabaseReplication. Is this
>  appropriate/recommended or does something need to be initiated from
>  the master? Previously, I would run a slon process on the master
>  and a slon on the slave but this seems much easier. Almost too good
>  to be true.

Where you run the slon processes and where you run configuration
scripts is your choice; in our environment, we have devoted database
servers, as well as "utility servers", and we run slon processes and
slonik configuration from the "utility servers."

There are good things about running everything from one spot, as that
means:
 - You don't have scripts (slonik and otherwise) strewn across a bunch
   of servers

 - You have a single view of all the slon processes, and can be sure
   they are all running or stopped without needing to ssh to other
   hosts

> Lastly, I just wanted to say that the altperl scripts are so much
> easier to deal with and they do seem to make life a lot easier.

If only we had someone doing more maintenance on them...
-- 
(format nil "~S@~S" "cbbrowne" "linuxfinances.info")
http://cbbrowne.com/info/internet.html
Rules of the  Evil Overlord #60. "My five-year-old  child advisor will
also  be asked to  decipher any  code I  am thinking  of using.  If he
breaks the code  in under 30 seconds, it will not  be used. Note: this
also applies to passwords." <http://www.eviloverlord.com/>