Thanks Elein. I'll run gdb and step through slonik_failed_node to (maybe)
see if failedNode2 is failing.


On 10/4/05, elein <elein at varlena.com> wrote:
>
> Fiel,
>
> In my own tests, with node 10->20->30, failover from 10 to 20 failed
> because node 30 was unusable and had to be recreated from scratch.
> This is a serious bug in my book.
>
> In one case the problem seemed to be dropping the first node
> "too soon". I have not tested that case so I don't know that
> this was the problem.
>
> What I have verified is that the third node never recieved any message
> regarding the failover and did not change its information
> to get its table set from the new origin, 20.
>
> Also, try not to use Node 1, 2, 3. Node 1 has some special meaning
> in some cases that you will want to avoid.
>
> We are with you, not ignoring you.
>
> --elein
>
> On Tue, Oct 04, 2005 at 11:13:19AM -0400, Fiel Cabral wrote:
> > Right after running the failover command I issue the DROP NODE command
> to drop
> > node 1. slonik prints an error message and exits with return value 12:
> >
> > sys:17: TRY: drop node
> > sys:19: PGRES_FATAL_ERROR select "_whatever".dropNode(1); - ERROR:
> Slony-I:
> > Node 1 is still origin of one or more sets
> >
> > Something should have changed the origin to node 3 but it isn't
> happening.
> >
> >
> > On 10/4/05, Fiel Cabral <e4696wyoa63emq6w3250kiw60i45e1 at gmail.com>
> wrote:
> >
> > I have 3 nodes. Nodes 2 and 3 are subscribers of node 1 and I'm trying
> to
> > failover from node 1 to node 3. The failover command succeeds but the
> > database of node 3 is still read-only and the origin is still node 1. I
> > don't have the same problem when doing failover with only two nodes
> because
> > the set is moved immediately by failedNode.
> >
> > failedNode (in the code below) is able to set the provider successfully.
> >
> > Some code elsewhere is actually moving the replication set. Where is
> that
> > code? Is it in slon or slonik or in the sql scripts?
> >
> > How do I find out that slon caught the signal and is doing the right
> thing
> > in response to the signal?
> >
> > 784 raise notice ''failedNode: set % has other direct receivers -
> > change providers only'', v_row.set_id;
> > 785 -- ----
> > 786 -- Backup node is not the only direct
> > subscriber. This
> > 787 -- means that at this moment, we redirect
> > all direct
> > 788 -- subscribers to receive from the backup
> > node, and the
> > 789 -- backup node itself to receive from
> > another one.
> > 790 -- The admin utility will wait for the slon
> > engine to
> > 791 -- restart and then call failedNode2() on
> > the node with
> > 792 -- the highest SYNC and redirect this to it
> > on
> > 793 -- backup node later.
> > 794 -- ----
> > ... etc ...
> > 811
> > 812 -- ----
> > 813 -- Make sure the node daemon will restart
> > 814 -- ----
> > 815 notify "_ at CLUSTERNAME@_Restart";
> > 816
> >
> > -Fiel
> >
> >
> >
> >
> >
> >
>
> > _______________________________________________
> > Slony1-general mailing list
> > Slony1-general at gborg.postgresql.org
> > http://gborg.postgresql.org/mailman/listinfo/slony1-general
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://gborg.postgresql.org/pipermail/slony1-general/attachments/20051004/12f246f2/attachment.html