Christopher Browne cbbrowne
Wed Jun 29 16:02:33 PDT 2005
Victoria Parsons wrote:

> Hi,
>
> I am replicating a database out and the slaves need to keep logs of
> changes to some tables. Before replication, I had a
> tablename_changelog. Whenever the table <tablename> gets data
> inserted/updated/deleted it followed a rule to write the old and new
> data to the changelog. There is a rule on the change log that sends
> out a notify when it is written to.
>
> Now that I am replicating the main table data down, I only want to
> keep these changelog tables on each slave, not on master. The problem
> I have is that when slony sets itself up in my database it removes (or
> hides) the rules on <tablename> that write my changes into the
> changelog table. These rules won't adversly affect my replication as
> they don't ever write into the replicated table, only read from. I can
> add them back in after replication is setup, but then I hit
> difficulties trying to anything else with slonik commands, like
> uninstall table or node, as these rules "shouldn't" be there. I'm
> assuming this will break any change of master scripts aswell.
>
> Is there anything clever I can do other than setup replication, create
> rules on slaves, remove the extra rules on slaves before
> uniinistalling/changing master node, then recreate rules afterwards.
>
May I point you to the STORE TRIGGER command?

<http://linuxfinances.info/info/stmtstoretrigger.html>

That allows triggers to be "reactivated."

The effect there is that the triggers are applied to ALL nodes; that may
not be exactly what you want.

It would be a neat idea to improve the STORE TRIGGER command so that
triggers could be activated just on a particular set of nodes.

The challenging part would be to 'reshape' the triggers when something
like MOVE SET is run.  It could take a fair bit of configuration
information to handle that for general cases.  Indeed, configuring that
to be handled "automagically" strikes me as requiring a pretty
complicated configuration scheme :-(.

It's certainly not impossible; a carefully thought-out proposal for how
to handle it needs to emerge...


More information about the Slony1-general mailing list