[EMAIL PROTECTED] ("Brendan Jurd") writes:
> On 11/11/06, Chris Browne <[EMAIL PROTECTED]> 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
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
