Jeff Amiel <jamiel at istreamimaging.com> writes:
> I spent yesterday getting my 7.4.2 database replication up and running.
> 33 tables and 15 sequences....all being replicated from my master 
> (production) system to my slave (backup).
> Very impressed with how painless it was (used the FreeBSD port for 
> installation).
> I'll spend the rest of the week benchmarking to see what kind of impact 
> it will have on my cpu/network/io.
>
> Some questions I have don't seem to be covered in the (so far) limited 
> documentation.  Laziness prevents me from looking at the source and 
> stored procedures so I present my questions here:
>
> 1.  How do I stop the sync 'gracefully'?  So far I've been kill -9ing 
> the slon daemon process on master or slave to halt it.  That can't be right.

I'm not sure what the BSD port has set up in terms of scripts; what
seems to be commonly used in the "scripts" people have been working
with is a sort of two layer thing:

 - The "slon_start" script starts up a slon instance, and a "watchdog" script

 - The "watchdog" script restarts slon within 30s if it dies

My "slon_kill.pl" script looks for all of these and shuts them all
down.

> 2.  Logging.  I notice that the slon daemon has a -d (debug level)...but 
> where does slony logging end up?

Depends on how you start it up; output heads to stdout/stderr, which
may be intercepted into files.

> 3.  Vacuuming.  Does it have any effect on the replication process?  I 
> assume that the 'slave' database will end up needing vacuuming just as 
> often as the master, so will the 'denyaccess()' function call that's 
> attached to every add/update/delete in my slave database prevent me from 
> vacuuming it?  Should I halt replicate before vacuuming?

Vacuuming doesn't require doing a visible update on the table, and is
unaffected by denyaccess().

> 4.  If I lose my master database, and want to move my backup box/db
> into production, wont the dennyaccess() triggers placed on the
> database prevent me from 'functioning' properly?

You'll presumably want to use FAILOVER/MOVE SET to switch the backup
to become "master."

Whether you do that via slonik or via the stored procedures, that will
lead to the denyaccess() triggers being dropped, and, more than
likely, the "update capturing triggers" getting added.

There's more than one way to accomplish this depending on how you
intend to "fail over" to the new node.
-- 
"cbbrowne","@","ca.afilias.info"
<http://dev6.int.libertyrms.com/>
Christopher Browne
(416) 673-4124 (land)