On Mon, Feb 8, 2010 at 12:19 PM, Tory M Blue <tmblue at gmail.com> wrote:
> So after last weeks discussion I'm still running into issues trying to
> remove a forwarder  and replace it with another forwarder talking to
> the remaining replica.
>
> To keep things simple.
>
> 1-2
> 1-3
> 2-4
>
> Set 1
>
> Want to remove  the forwarder (2), and since the origin is not moving,
> doesn't seem a fail-over or switchover fits the bill here.
>
> I've tried to simply drop the path of 2 and run a simple subscribe set
>  ( id=1,  provider=3, receiver=4); but the replica seems to get
> confused and without restarting slony on the replica  things don't
> seem to ever catch up.
>
> Since I'm not replacing the origin and just a forwarder, are there
> steps that I should be doing vs just issuing a subscribe to another
> forwarder?, I don't want to unsubscribe, I just want the replica to
> get it's updates from forwarder (3) now.
>
> When i drop node 2, here is what I've tried.
>
> SLONIK_COMMANDS="$SLONIK_COMMANDS
>        SUBSCRIBE SET ( ID = 1, PROVIDER = 3, RECEIVER = 4, forward = no);
>        WAIT FOR EVENT ( ORIGIN = 3, CONFIRMED = 4 ) ; <-- run with and without
>        UNSUBSCRIBE SET ( ID = 1, RECEIVER = 2);
>       DROP PATH ( SERVER = 2, CLIENT = 4 );
>       DROP PATH ( SERVER = 4, CLIENT = 2 );
>       DROP PATH ( SERVER = 1, CLIENT = 2 );
>       DROP PATH ( SERVER = 2, CLIENT = 1 );
>
> This sometimes works and other times does not, again it seems if I
> restart the replica (4) things are happy, but I feel that there is
> something I'm doing wrong, or out of order?

So after much much more trial and error and finding "stuff" I had
broke, I understand that my subscribe set is pretty much all I need to
do to move a forwarder.

However I don't know if it's me dropping paths soon after or what, but
my replica after being told to listen/communicate with the new
forwarder still doesn't.

Forwarder 3 - replica 4
-to-
Forwarder 2 - replica 4

2010-02-08 21:19:06 PST DEBUG2 remoteWorkerThread_1: SYNC 1605 processing
2010-02-08 21:19:06 PST DEBUG2 remoteWorkerThread_1: data provider 3
confirmed up to ev_seqno 1605 for ev_origin 1 - OK
2010-02-08 21:19:06 PST DEBUG2 remoteWorkerThread_1: syncing set 1
with 14 table(s) from provider 3
2010-02-08 21:19:06 PST DEBUG4  ssy_action_list value:

sl_path is correct on the replica:
 sub_set | sub_provider | sub_receiver | sub_forward | sub_active
---------+--------------+--------------+-------------+------------
       1 |            1 |            3 | t           | t
       2 |            1 |            2 | t           | t
       3 |            1 |            2 | t           | t
       1 |            1 |            2 | t           | t
       1 |            2 |            4 | f           | t

yet until I kill slon and restart it on the replica, it will never
reflect the changes. This makes no sense to me and is what is causing
me some issues. Heck most of you thought i was nuts when I didn't have
slon started when I was setting things up and yes I've learned that
most of slony tasks do not require any type of "service" modification,
however in this scenario I seem to have to. And as noted in the docs
the subscribe set returns immediate results so you can't utilize a
wait for event (at least with 1.2).

So what would cause me to have to restart slon for the changes to take
affect, when as i've shown above the paths on this replica are
correct, a restart of slon makes everything nice and dandy, just
thinking that is not something I should be doing.

On restart of slon on the replica

2010-02-08 21:26:19 PST DEBUG2 calc sync size - last time: 1 last
length: 1184 ideal: 50 proposed size: 3
2010-02-08 21:26:19 PST DEBUG2 remoteWorkerThread_1: SYNC 1649 processing
2010-02-08 21:26:19 PST DEBUG2 remoteWorkerThread_1: syncing set 1
with 14 table(s) from provider 2
2010-02-08 21:26:19 PST DEBUG4  ssy_action_list value:
2010-02-08 21:26:19 PST DEBUG2  ssy_action_list length: 0

Thanks again
Tory