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)
_______________________________________________
Slony1-general mailing list
[email protected]
http://lists.slony.info/mailman/listinfo/slony1-general
