direvus@xxxxxxxxx ("Brendan Jurd") writes: > On 11/11/06, Chris Browne <cbbrowne@xxxxxxx> wrote: >> Let me point out one possible downside to using Slony-I log shipping; >> it may not be an issue for you, but it's worth observing... >> >> Log shipping works via serializing the subscription work done on a >> subscriber to files. Thus, you MUST have at least one subscriber in >> order to have log shipping work. If that's a problem, that's a >> problem... > > So I would have a normal Slony subscriber sitting somewhere on the > internal network, which pushes its log files out to the remote server. > And the remote server then has a process sitting on it which inhales > the log files into the database as they arrive. > > Have I got the right idea? Exactly. > Why *does* Slony require a bi-directional connection to the > subscriber? The data is travelling in one direction only ... what > needs to come back the other way? - So that any node might be promoted to be origin in case of emergency. - So that nodes know when logged data (sl_log_{1,2}) can be safely purged. > This seems to be getting rather messy. I wonder if I might not be > better off just writing AFTER triggers on all the tables I'm > interested in, which replicate the query to the slave system with > psql. It would probably be relatively labour intensive, and > increase the burden of administering the schema, but it would also > be a much more direct and simple approach. There might be some improved elegance in that; it is quite possible that Slony-I has more functionality than you need. -- "cbbrowne","@","linuxdatabases.info" http://linuxfinances.info/info/slony.html "In man-machine symbiosis, it is man who must adjust: The machines can't." -- Alan J. Perlis