A few weeks ago I was looking for a way to get around slony scalability issues for a large network of machines that need a replication relationship. The log shipping approach Christopher mentioned sounds promising, but I have to deliver something, hmmm, a couple of weeks from now....(sigh)

The approach I'm thinking of involves leveraging the existing slony infrastructure I have, but implementing my own "push" process. This process maintains its own little schema to manage subscribers, etc., but it listens on sync events and uses the slony sl_log table(s) to capture the updates. Then it pushes these updates out to wherever it needs to. The requirements for synchronization here are somewhat looser, so I'm just tracking the lastest transaction id on every subscriber node. 

The main reason for this approach is to avoid the overhead of the n-1 connections to every node in the system, and also to avoid de-stabilizing our existing slony-based clustering/failover infrastructure, which is working fine as it is.

One thing I'm wondering about is the logic in the cleanup thread that cleans out the sl_log_1 table: the logic appears to be keying off of the min(ev_seqno) in the sl_event table to determine what the floor on the xid is should be in the log table, but it's not clear to me where the events get managed. Obviously it's all right there in front of me in SQL or C code, but I keep getting confused by what's happening in what thread....

Also, at what point does the switch get made from sl_log_1 to sl_log_2?

TIA for any suggestions.


- DAP
----------------------------------------------------------------------------------
David Parker    Tazz Networks    (401) 709-5130
?