I'm still trying to add some rules back into my replicated (slave) databases. Its not going too bad but I'm at a point where I'm stuck and looking for a clue.

After subscribing a slave node to the master I run a script that inserts all the rules I need. Before unsubscribing the set for any reason I run a script to remove them all. This all works fine and I can start and stop the replication without any errors caused.

The problem is that if I start inserting the rules immediately after issuing the subscriber set command the "new" rules get deleted as the set subscribes. So I got round it by adding a sleep for 5 seconds between subscribing and adding new rules. When the rules are in the slavedb they work fine, but it means they didn't fire for some of the first data that got copied by copy set (because I was still sleeping while it happened) 

I can't see any way around this without modifying slony source as the subscribe set rolls it all into a single command. 
So my two potential plans for going forward are
a) try and split the subscribe set command into a 'remove rules and triggers' phase and a 'start replicating' phase. 
b) trying to copy the 'store trigger' function to make a 'store rules' function. 

I've had a brief look at the source and can't decide where to start. Can anyone suggest why one or both of these ideas wouldn't work or which might be easiest to implement.

Cheers,
Vicki Parsons  



-----Original Message-----
From: Hannu Krosing [mailto:hannu at skype.net]
Sent: 29 June 2005 17:36
To: Christopher Browne
Cc: Victoria Parsons; Slony Mailing List
Subject: Re: [Slony1-general] adding rules to replicated tables


On K, 2005-06-29 at 11:02 -0400, Christopher Browne wrote:
> Victoria Parsons wrote:
> 
> > Hi,
...
> > 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."

How does this relate to RULEs ?

Slony disables both triggers and rules, but provides only a command for
reactivating triggers.

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

Same for EXECUTE SCRIPT - it would be much better, if the script couls
be executed onyl on a set of nodes (same as defined by a slony set).

> 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 :-(.

If this would be uniquely defined by a slony set, no additional info
would be needed.

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



-- 
Hannu Krosing <hannu at skype.net>


-- 
This message has been scanned for viruses and potentially
harmful content by StreamShield Protector.



This message should be regarded as confidential. If you have received this email in error please notify the sender and destroy it immediately.
Statements of intent shall only become binding when confirmed in hard copy by an authorized signatory.


-- 
This message has been scanned for viruses and potentially
harmful content by StreamShield Protector.