Michael Weber wrote:
> Christopher,
>
> thanks a lot for the comments,
>
> test_slony_state did not report anything out of the usual (when
> running against the master, against the slave nodes it reported some
> missing listen paths from 3 to 1), and there were no ERRORs in the
> logfile of node2 & node3. But there were also no INSERTS with a
> rowcount higher than zero (the database is not very busy usually,
> daytime it is one row per 5 minutes). But sl_log_2 had many rows, and
> was growing.
>
> Unfortunately I got annoyed by the problem, dropped the slony schemas,
> truncated the replicated tables, recreated & started slony (thanks to
> the nice slonik_scripts a piece of cake). All of this took 10 minutes,
> even though I would have liked to find the actual problem.
>
> I think I messed up the system last week in trying to get replication
> started on node2 without node3 being up-to-date (version wise), and
> not knowing that node3 was running out of disk space.
>
> Thanks again for your help, and sorry for not reading enough before
> asking stupid questions (I read about the test script only yesterday,
> and I had never looked into the sl_* tables before yesterday either.
>   
You asked questions eventually, so that's a good thing ;-).  
Unfortunately, Slony-I isn't entirely forgiving to "uncarefulness." :-(
> About the setup:
> I have 2 sets: set1 master  is on Tenerife, node2 and node3 are two
> machines here in Potsdam (D). set2 master is node2, node3 is the copy
> of it (it is data created in Potsdam from the Tenerife data). That is
> why I pull the data for node3 from node2 (a tip I had gotten on this
> list).
>
> Another question: We have mostly meta-data in our database, the "real"
> data is kept in binary files transported via rsync (8 to 32MB
> uncompressed, compresses to about half). Would postgresql & slony be
> efficient in handling those things also?
>   
Hmm.  If you use ssh connections (an option in pg_hba.conf), or set up 
an ssh tunnel, then that could compress the data "in flight" between 
sites, which could reduce bandwidth usage over uncompressed handling.

In our environment, we haven't done that, but it *might* make using 
Slony-I as transport at least comparable to rsync.

Slony-I basically uses plain SQL statements, so you can use things like 
ssh tunnelling or ssh connections to improve things over uncompressed 
behaviour.  I don't imagine that would be notably *better* than rsync, 
but I'd expect it to be "not much worse."

-- 
let name="cbbrowne" and tld="ca.afilias.info" in name ^ "@" ^ tld;;
<http://dba2.int.libertyrms.com/>
Christopher Browne
(416) 673-4124 (land)