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? 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? 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. BJ
