Geoffrey <lists at serioustechnology.com> writes:
> I can't seem to figure out what 'mechanism' actually causes
> replication. That may be a too simplistic view of the whole process,
> but the bottom line is, I have to make sure that our manipulation of
> the 'session_replication_role' is going to properly address the issue
> of insuring slony continues to replicate our data.
>
> Is it the '_pro_cluster_logtrigger_1' trigger in the NODE 1 Database
> that is responsible for the actual replication process?
>
> That is, if I do the following:
>
> ALTER TABLE foo ENABLE ALWAYS TRIGGER _pro_cluster_logtrigger_1;
>
> I'm assuming that the replication will not be interrupted as this
> trigger will always fire regardless of the 'session_replication_role'
> setting.
>
> Another way of putting it is, is it the '*_logtrigger_1' trigger that
> is added to replicated tables responsible (directly or indirectly) for
> the actual replication of data.
>
> I say 'directly or indirectly' as I see that this trigger runs the
> procedure _pro_cluster.logtrigger, and without looking into that
> procedure mechanism, it's possible that it has a cascading effect that
> ultimately effects the replication of data.
>
> Please understand, I realize our current approach is not the best
> solution, but, I don't set the priorities and replication is higher on
> the list, then changing the way our application works.

In a sense, it's *ALL* a big indirection.

Slony-I started by implementing an event management system, to get
events propagating between the nodes.

Once you've got that, replicating data is a convenient side-effect
:-).

Having replication working requires several things cooperating...

- The "logtrigger" triggers running on the origin collect data into
  sl_log_*.

- You need to have a slon working against the origin, marking off SYNC
  events every so often, which allows us to do incremental processing
  of replication data.

- The slon process connected to the subscriber listens for SYNC
  events, which tell it "Hey, we may have some new data for you!"
  SYNC information allows the subscriber to identify which data to
  look for in sl_log_*.

At the end of all that, you have replication.
-- 
(format nil "~S@~S" "cbbrowne" "cbbrowne.com")
http://linuxfinances.info/info/linuxxian.html
Jury  -- Twelve  people  who  determine which  client  has the  better
lawyer.