Slony1 PostgreSQL Replication - Wait for event before subscribing

Author

Wait for event before subscribing

Victoria Parsons

2006-02-25, 9:50 am

Hello,

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.

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?

Thanks for you help,
Vicki

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.

Christopher Browne

2006-02-25, 9:50 am

"Victoria Parsons" <victoria.parsons- UVxggvuNoGJxTUc3asy8
/Q@public.gmane.org> 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)

Jim C. Nasby

2006-02-25, 9:50 am

On Thu, Feb 23, 2006 at 11:00:49AM -0500, Christopher Browne wrote:
> "Victoria Parsons" <victoria.parsons- UVxggvuNoGJxTUc3asy8
/Q@public.gmane.org> writes:
>
> 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.

Hrm... are there any error codes returned from a command? Or perhaps if
there was a way to tell wait to ignore certain errors. Basically, there
are conditions that won't create a mess to cleanup and those that will,
so it would be good if there was some way to differentiate (of course,
different people will have different ideas as to what a 'mess' is...)
--
Jim C. Nasby, Sr. Engineering Consultant jnasby-D/ iDPWeZeLdl57MIdRCFDg
@public.gmane.org
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461

Sponsored Links