"Tang, Jason" <jason.tang at teamuk.telstra.com> writes:
> Yeah something like that I eventually found out something like this
> seemed to do what I was after. Not sure if its the CORRECT way reset the
> configuration back to square one, but seems to work
>
> slonik <<_EOF_
> cluster name = $CLUSTER;
>
> node 1 admin conninfo = 'dbname=$DBNAME1 host=$HOST1 user=$SLONY_USER';
> node 2 admin conninfo = 'dbname=$DBNAME2 host=$HOST2 user=$SLONY_USER';
> uninstall node ( id = 1 );
> uninstall node ( id = 2 );
>
> I don't suppose anyone can recommend some good links that provide easy
> to follow instructions for common things you'd want to do to a cluster?
> To stop the slon daemon I'm using kill -9 :)

Those are indeed reasonable things to do...

If you look at the "slon_kill" script in the altperl directory, you'll
find that it takes much that approach.  We have a script that we use
in production which starts with "kill -2", waits a bit, does "kill
-3", and if the process persists, "kill -9".

If you're monitoring logs, it's probably preferable to start with
"less intense" termination parameters so that there's a chance for the
process to die a bit cleanly...

> I'm also a tad confused. I think I've configured everything and then
> start slon on master/slave but not sure where it goes any logging to
> show that its doing something.

You're starting with a misunderstanding that is actually vital...

As far as slon is concerned, there is no "master" or "slave."  They
are just nodes.

What you can expect, initially, is to see, on both nodes, some events
propagating back and forth.  Firstly, there should be some events
published to indicate creation of the nodes and paths.  If you don't
see those, then the nodes aren't likely to be able to communicate with
one another, and nothing else will happen...

You'll set up the set, add tables, and sequences, and will see
relevant events only on the origin node.

Then, when you submit the SUBSCRIBE SET request, the event should go
to both nodes.

The origin node has little more to do...  The subscriber will then
have a COPY_SET event, which will lead to logging information about
adding each table and copying its data.

After that, you'll see two sorts of behaviour:

1.  On the origin, there won't be much logged, just indication that
some SYNC events are being generated and confirmed by each other.

2.  On the subscriber, there will be reports of SYNCs and that the
subscriber pulls data from the provider for the relevant set(s).

> Other than create a db on the slave machine, do I need a snapshot of
> the master? Is this stage optional?

You need the schema from the master.  I'm not quite sure what you're
indicating by "stage"...

> Slon seems to be outputting the following and doesn't seem to be doing
> anything else. Whats it waiting for? I've done an insert no the master
> and nothing seems to be coming through and I've used the same starting
> point as the master.
>
> CONFIG main: slon version 1.0.5 starting up
> CONFIG main: local node id = 1
> CONFIG main: loading current cluster configuration
> CONFIG storeNode: no_id=2 no_comment='Node 2'
> CONFIG storePath: pa_server=2 pa_client=1
> pa_conninfo="dbname=prod_provision host=154.8.2.51 user=pgsql"
> pa_connretry=10
> CONFIG storeListen: li_origin=2 li_receiver=1 li_provider=2
> CONFIG storeSet: set_id=1 set_origin=1 set_comment=''
> CONFIG main: configuration complete - starting threads
> CONFIG enableNode: no_id=2

This is what both nodes are reporting???

That seems consistent with the node being devoid of configuration
about the nodes.

It seems to me that what you need to do is to progressively configure
things, and take a look to see that each step "takes."

1.  Create the two nodes.

2.  Start the 2 slons.  They'll start out very quiet, like the above.

3.  STORE PATH for the communications paths.  That should allow the
nodes to become aware of one another.

Look at the contents of sl_path, sl_node; if there are 2 nodes, then
you should have 2 entries in each of those tables on both nodes after
doing the STORE PATH.  (Possibly you'll have one sl_path on each
node.)

4.  STORE LISTEN to indicate how the nodes will use the paths.

After doing this, the nodes should start a greater "flood" of activity.

Both should submit SYNC events every so often.

Look at sl_path, sl_node, sl_listen on each node.  There should be 2
rows in each table.  

If not, then communications won't be working right, and your
efforts/questions should target fixing this.  Don't try to go on to
later steps if the nodes aren't communicating; you would just be
wasting your time on the wrong problem.

5.  CREATE SET, SET ADD TABLE, SET ADD SEQUENCE

This will only affect the origin node, initially.  But once you have
tables added, updates to the tables should cause SYNCs to happen more
often in the logs.

6.  SUBSCRIBE SET

This should lead to a bunch of activity on the subscriber node, where
there will be a whole bunch of sub-events to set up the replication
set on the subscriber node, and to copy the data from the provider.

Afterwards, there will be SYNCs (more often when there are updates
taking place at the origin) that will lead to the subscriber grabbing
data, and logging a bit about what it's doing.

I'm going to see about adding the above to the documentation section
on monitoring; that's the first that I have tried to document the
differences between these various "phases."
-- 
"cbbrowne","@","ca.afilias.info"
<http://dev6.int.libertyrms.com/>
Christopher Browne
(416) 673-4124 (land)