"Victoria Parsons" <victoria.parsons at streamshield.com> writes:
> Is it really necessary, when creating a new set and subscribing it
> that a wait for event is done after the set creation? Won't the
> requests get queued and so are guaranteed to be processed on the
> subscriber in the right order. The reason I ask is because I have a
> single set currently replicating to many slaves. I want to add a
> second set with a single table to go from the same master to all
> slaves (with the intent of eventually performing a merge set). If
> one of the slaves is temporarily down (network outage or turned
> off), I want to be able to create the set on the master and issue a
> subscribe set to all nodes, so that all the OK nodes pick it up
> straightaway and when the bad node comes back it will process create
> set, set add table, and subscribe set in the right order. By putting
> a wait for event after the create set (and add tables) I won't be
> able to subscribe any nodes until all including the bad one confirm.

Yes, you can have extra events "queued" up...

It basically introduces the risk that you might, if there is a problem
with the slonik submissions, queue up a series of *bad* events, and
have more complex cleanup to do if one of the early ones breaks.

> I just did a test on a single slave by stopping the network, issuing
> the commands on the master, and then restarting the slaves
> network. The slon daemon serving it did bomb out with errors, but
> when my watchdog restarted it, it seem ok then, ad changes I had
> made to new and old tables whilst the slave was down replicated
> through correctly. Did I just get lucky or is this ok to do?

You were a bit lucky, that the problem you hit wasn't something that
would repeat over and over.  It's OK to be lucky :-).
-- 
let name="cbbrowne" and tld="ca.afilias.info" in String.concat "@" [name;tld];;
<http://dba2.int.libertyrms.com/>
Christopher Browne
(416) 673-4124 (land)