Slony1 PostgreSQL Replication

Author

(no subject)

Tang, Jason

2005-06-10, 1:24 pm

Hi All,

I've been gifted with the task of implementing replication. I've had it
replicating a simple db. However now I'm going to be doing it for real
and the actual db has far too many tables/sequences to do it by hand.
I'm wondering if anyone out there has been through the exercise of
writing something to pull out and generate a file to describe the set as
a starting point.

I thought I'd ask on here as it seems silly to potentially reinvent the
wheel again. Any related links you guys could direct me towards?

TIA
Kind regards

Jason Tang
Software Developer

Scott Marlowe

2005-06-10, 1:24 pm

On Fri, 2005-06-10 at 11:04, Tang, Jason wrote:
> Hi All,
>
> I've been gifted with the task of implementing replication. I've had it
> replicating a simple db. However now I'm going to be doing it for real
> and the actual db has far too many tables/sequences to do it by hand.
> I'm wondering if anyone out there has been through the exercise of
> writing something to pull out and generate a file to describe the set as
> a starting point.
>
> I thought I'd ask on here as it seems silly to potentially reinvent the
> wheel again. Any related links you guys could direct me towards?

I think there's some perl scripts to do it, but here's my super simple
bash script that creates a list of all the tables and sequences to
replicate in a database

echo "create temp sequence tc;
SELECT
'set add table (set id=1, origin=1, id='||nextval('tc')|
|', fully
qualified name = ''public.'||c.relname||'', comment='');' as \"Name\"
FROM
pg_catalog.pg_class c
LEFT JOIN
pg_catalog.pg_user u
ON
u.usesysid = c.relowner
LEFT JOIN
pg_catalog.pg_namespace n
ON
n.oid = c.relnamespace
WHERE
n.nspname='public' and
c.relkind IN ('r','v','S','') and
n.nspname NOT IN ('pg_catalog', 'pg_toast') and
pg_catalog. pg_table_is_visible(
c.oid)
order by 1;
drop sequence tc;"|psql $MASTERDBNAME -t

It relies on the $MASTERDBNAME variable being set so it knows which db
to hit. Pretty straight forward, I'm sure it could use some
prettification.

Christopher Browne

2005-06-10, 1:24 pm

Tang, Jason wrote:

>Hi All,
>
>I've been gifted with the task of implementing replication. I've had it
>replicating a simple db. However now I'm going to be doing it for real
>and the actual db has far too many tables/sequences to do it by hand.
>I'm wondering if anyone out there has been through the exercise of
>writing something to pull out and generate a file to describe the set as
>a starting point.
>
>I thought I'd ask on here as it seems silly to potentially reinvent the
>wheel again. Any related links you guys could direct me towards
>
>
There's a tool in the "altperl" directory that is called "build_env.pl"
or "slonik_build_env.pl" which tries to build a config file for the
"altperl" tools as a starting point for you.

Other than that, it wouldn't be too hard to build a query that rummages
around in the information_schema namespace for table and sequence names
and generates, as output, a set of "set add table" and "set add
sequence" statements.

Thomas F. O'Connell

2005-06-11, 3:29 am

A while back, I put together meta-slonik for just this purpose.

http://www.sitening.com/meta-slonik

--
Thomas F. O'Connell
Co-Founder, Information Architect
Sitening, LLC

Strategic Open Source: Open Your i=99

http://www.sitening.com/
110 30th Avenue North, Suite 6
Nashville, TN 37203-6320
615-260-0005

On Jun 10, 2005, at 1:25 PM, Christopher Browne wrote:

> Tang, Jason wrote:
>
>
> There's a tool in the "altperl" directory that is called =20
> "build_env.pl"
> or "slonik_build_env.pl" which tries to build a config file for the
> "altperl" tools as a starting point for you.
>
> Other than that, it wouldn't be too hard to build a query that =20
> rummages
> around in the information_schema namespace for table and sequence =20
> names
> and generates, as output, a set of "set add table" and "set add
> sequence" statements.

Tang, Jason

2005-06-13, 7:24 am

Thanks for this. This exactly what I'm after!

Due to my own sloppiness I hadn't set up the slave correctly. It seems I
can rerun the same script. Is there a process I have to go through to
undo what has been done on the master so I can start from scratch from a
slony point of view?

TIA
Jase
[color=darkred]
> -----Original Message-----
> From: Thomas F. O'Connell [mailto:tfo- pes1XBtKsyuK7kMhnKJN
1Q@public.gmane.org]
> Sent: 11 June 2005 05:41
> To: Christopher Browne
> Cc: Tang, Jason; slony1-general- AuKwsB3Fm+ugFIWk8tvy
RWD2FQJk+8+b@public.gmane.org
> Subject: Re: [Slony1-general] (no subject)
>=20
> A while back, I put together meta-slonik for just this purpose.
>=20
> http://www.sitening.com/meta-slonik
>=20
> --
> Thomas F. O'Connell
> Co-Founder, Information Architect
> Sitening, LLC
>=20
> Strategic Open Source: Open Your i(tm)
>=20
> http://www.sitening.com/
> 110 30th Avenue North, Suite 6
> Nashville, TN 37203-6320
> 615-260-0005
>=20
> On Jun 10, 2005, at 1:25 PM, Christopher Browne wrote:
>=20
hand.[color=darkred]

Thomas F. O'Connell

2005-06-14, 3:24 am

Jason,

Are you talking about something different from the various dropping =20
functionalities in Slony?

http://developer.postgresql.org/~wi...ide-1.1.rc1/=20
dropthings.html

--
Thomas F. O'Connell
Co-Founder, Information Architect
Sitening, LLC

Strategic Open Source: Open Your i=99

http://www.sitening.com/
110 30th Avenue North, Suite 6
Nashville, TN 37203-6320
615-260-0005

On Jun 13, 2005, at 6:54 AM, Tang, Jason wrote:

> Thanks for this. This exactly what I'm after!
>
> Due to my own sloppiness I hadn't set up the slave correctly. It =20
> seems I
> can rerun the same script. Is there a process I have to go through to
> undo what has been done on the master so I can start from scratch =20
> from a
> slony point of view?
>
> TIA
> Jase

Tang, Jason

2005-06-14, 9:24 am

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 =3D $CLUSTER;

node 1 admin conninfo =3D 'dbname=3D$DBNAME1 host=3D$HOST1 =
user=3D$SLONY_USER';

node 2 admin conninfo =3D 'dbname=3D$DBNAME2 host=3D$HOST2 =
user=3D$SLONY_USER';

uninstall node ( id =3D 1 );
uninstall node ( id =3D 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 :)

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.

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

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 =3D 1
CONFIG main: loading current cluster configuration
CONFIG storeNode: no_id=3D2 no_comment=3D'Node 2'
CONFIG storePath: pa_server=3D2 pa_client=3D1
pa_conninfo=3D" dbname=3Dprod_provis
ion host=3D154.8.2.51 user=3Dpgsql"
pa_connretry=3D10
CONFIG storeListen: li_origin=3D2 li_receiver=3D1 li_provider=3D2
CONFIG storeSet: set_id=3D1 set_origin=3D1 set_comment=3D''
CONFIG main: configuration complete - starting threads
CONFIG enableNode: no_id=3D2

Jason
[color=darkred]
> -----Original Message-----
> From: Thomas F. O'Connell [mailto:tfo- bII3nen9HKpWk0Htik3J
/w@public.gmane.org]
> Sent: 14 June 2005 06:51
> To: Tang, Jason
> Cc: Slony Mailing List
> Subject: Re: [Slony1-general] (no subject)
>=20
> Jason,
>=20
> Are you talking about something different from the various dropping
> functionalities in Slony?
>=20
> http://developer.postgresql.org/~wi...nguide-1.1.rc1/
> dropthings.html
>=20
> --
> Thomas F. O'Connell
> Co-Founder, Information Architect
> Sitening, LLC
>=20
> Strategic Open Source: Open Your i(tm)
>=20
> http://www.sitening.com/
> 110 30th Avenue North, Suite 6
> Nashville, TN 37203-6320
> 615-260-0005
>=20
> On Jun 13, 2005, at 6:54 AM, Tang, Jason wrote:
>=20
to[color=darkred]

Christopher Browne

2005-06-14, 11:24 am

"Tang, Jason" <jason.tang- UQ1CjVvcO09tmpO5GhRA
odBPR1lH4CV8@public.gmane.org> 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_provisio
n 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)

Tang, Jason

2005-06-14, 11:24 am

> -----Original Message-----
> 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".
>=20
> 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...

Noted. Less brutal :)

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

schema with no data?

doing[color=darkred]

master[color=darkred
]
starting[color=darkr
ed]
user=3Dpgsql"[color=darkred]
>=20
> This is what both nodes are reporting???

Yes very similar, that's on the master node. Below is slave node.=20

CONFIG main: slon version 1.0.5 starting up
CONFIG main: local node id =3D 2
CONFIG main: loading current cluster configuration
CONFIG storeNode: no_id=3D1 no_comment=3D'Primar
y Node 1'
CONFIG storePath: pa_server=3D1 pa_client=3D2
pa_conninfo=3D" dbname=3Dprod_provis
ion host=3D154.8.2.50 user=3Dpgsql"
pa_connretry=3D10
CONFIG storeListen: li_origin=3D1 li_receiver=3D2 li_provider=3D1
CONFIG storeSet: set_id=3D1 set_origin=3D1 set_comment=3D''
WARN remoteWorker_wakeup:
node 1 - no worker thread
CONFIG main: configuration complete - starting threads
CONFIG enableNode: no_id=3D1

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

I'll go through the list of things you've listed and see how it goes.

Thanks for all the help!

Jase

Tang, Jason

2005-06-15, 7:24 am

> > Slon seems to be outputting the following and doesn't seem to be
doing

master[color=darkred
]
starting[color=darkr
ed]
user=3Dpgsql"[color=darkred]
>=20
> 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."
>=20
> 1. Create the two nodes.
>=20
> 2. Start the 2 slons. They'll start out very quiet, like the above.

Yups I get this

> 3. STORE PATH for the communications paths. That should allow the
> nodes to become aware of one another.
>=20
> 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.)

2 entries in sl_node and one in sl_path

>=20
> 4. STORE LISTEN to indicate how the nodes will use the paths.
>=20
> After doing this, the nodes should start a greater "flood" of
activity.
>=20
> Both should submit SYNC events every so often.
>=20
> Look at sl_path, sl_node, sl_listen on each node. There should be 2
> rows in each table.
>=20
> 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.

I'm not getting _any_ SYNC events. Which aspect of the communication?
I've tested that each node can psql to the database on the other
machine. Or does the slon use a port separate to postgres?

> 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."

Definitely! I'm finding it very useful in tracking down what I'm doing
wrong.

Before these steps I create dbs on each node and shove a snapshot of the
schema complete with data too.

Cheers
Jase

Christopher Browne

2005-06-15, 9:24 am

"Tang, Jason" <jason.tang- UQ1CjVvcO09tmpO5GhRA
odBPR1lH4CV8@public.gmane.org> writes:
> doing
> master
> starting
>
> Yups I get this
>
>
> 2 entries in sl_node and one in sl_path

Once the slons get going, each node should have two entries in
sl_path. There's the first "root" of problems.

The puzzle: Why did the paths not propagate?

Is it possible that you only submitted one STORE PATH statement?

You may want to look at the sl_path data and see if it seems right or
wrong.

Note that if you missed something, you can always add it on the fly.
You can submit a slonik script without shutting anything down and do
an extra "store path".

There should also ultimately be 2 sl_listen entries on each node. It
might start as 1, before events start propagating...

Did you submit STORE LISTEN requests, as well? Things won't work
until that is set up...
[color=darkred]
> activity.
>
> I'm not getting _any_ SYNC events. Which aspect of the communication?
> I've tested that each node can psql to the database on the other
> machine. Or does the slon use a port separate to postgres?

slon uses a plain old PostgreSQL port to connect to the databases.

If you connect to one or the other database, while slons are running,
you should see connections in pg_stat_activity. If you use a separate
"slony" superuser rather than the generic "postgres" or "pgsql" user,
you'll see it more clearly...
--
"cbbrowne","@","ca.afilias.info"
<http://dev6.int.libertyrms.com/>
Christopher Browne
(416) 673-4124 (land)

Tang, Jason

2005-06-15, 9:24 am

> >> It seems to me that what you need to do is to progressively
configure
above.[color=darkred]
then[color=darkred]
after[color=darkred]

>=20
> Once the slons get going, each node should have two entries in
> sl_path. There's the first "root" of problems.
>=20
> The puzzle: Why did the paths not propagate?
>
> Is it possible that you only submitted one STORE PATH statement?

Nopes :) However I noticed once I sent the 'store listen' then indeed
there were two rows in sl_path on each node. I assume this is a Good
Thing(tm)?

=3D=3D=3D=3D
store path ( server =3D 1, client =3D 2, conninfo =3D 'dbname=3D$DBNAME1
host=3D$HOST1 use
r=3D$SLONY_USER');
store path ( server =3D 2, client =3D 1, conninfo =3D 'dbname=3D$DBNAME2
host=3D$HOST2 use
r=3D$SLONY_USER');
=3D=3D=3D=3D

>=20
> There should also ultimately be 2 sl_listen entries on each node. It
> might start as 1, before events start propagating...

After store listen I get two
[color=darkred]

Both nodes started with the same db dump before any of the slony stuff.
Still no sign of any floods of activity, not even a trickle :)

Any info you'd like me to send on to aid tracking problem down?

Jase

Christopher Browne

2005-06-15, 9:24 am

"Tang, Jason" <jason.tang- UQ1CjVvcO09tmpO5GhRA
odBPR1lH4CV8@public.gmane.org> writes:
> After store listen I get two

Oh, good. That's expected, and points to things being pretty close to
working.

You should now see that the slons each submit _some_ events back and
forth. Not much, but there should be a "back and forth" of some SYNCs
and confirmations thereof. Hmm. What's the default... There may be
just one event every minute or so per "otherwise-inactive" node. So
it's hardly a "world-threatening flood." :-)

>
> Both nodes started with the same db dump before any of the slony stuff.
> Still no sign of any floods of activity, not even a trickle :)
>
> Any info you'd like me to send on to aid tracking problem down?

The next step, I'd say, is to set up the replication set on the
"master," (e.g. - CREATE SET) add in the tables that are to be
replicated (e.g. - SET ADD TABLE) , and then submit a SUBSCRIBE SET.

That should give you some interesting activity...
--
"cbbrowne","@","ca.afilias.info"
<http://dev6.int.libertyrms.com/>
Christopher Browne
(416) 673-4124 (land)

Tang, Jason

2005-06-15, 11:25 am

> From: Christopher Browne [mailto:cbbrowne-swQf4SbcV9C7WVzo/KQ3Mw@public.gmane.org]
> You should now see that the slons each submit _some_ events back and
> forth. Not much, but there should be a "back and forth" of some SYNCs
> and confirmations thereof. Hmm. What's the default... There may be
> just one event every minute or so per "otherwise-inactive" node. So
> it's hardly a "world-threatening flood." :-)

Nothing mentioning SYNC at all.

Just these when do send the appropriate commands:

CONFIG storePath: pa_server=3D1 pa_client=3D2
pa_conninfo=3D" dbname=3Dprod_provis
ion host=3D154.8.2.50 user=3Dslony"
pa_connretry=3D10

CONFIG storeListen: li_origin=3D1 li_receiver=3D2 li_provider=3D1

stuff.[color=darkred]
>=20
> The next step, I'd say, is to set up the replication set on the
> "master," (e.g. - CREATE SET) add in the tables that are to be
> replicated (e.g. - SET ADD TABLE) , and then submit a SUBSCRIBE SET.

On the master I get NOTICE and CONTEXT activity after the CREATE SET and
SET ADD TABLE and SET SEQUENCES.

subscribe set ( id =3D 1, provider =3D 1, receiver =3D 2, forward =3D =
yes );

After the SUBSCRIBE SET the slave node activity mirrors the master's
NOTICE/CONTEXT messages and also gives;

CONFIG enableSubscription: sub_set=3D1

...then it goes quiet. Tried doing an insert, but not a sausage

Jase

Christopher Browne

2005-06-15, 11:25 am

"Tang, Jason" <Jason.Tang-EbOMXLyeCfLY0TyS/+Ba5Q@public.gmane.org> writes:
> ..then it goes quiet. Tried doing an insert, but not a sausage

Hmm. Maybe the logging isn't turned high enough :-).

Make sure the slon processes have "-d2", maybe?
--
"cbbrowne","@","ca.afilias.info"
<http://dev6.int.libertyrms.com/>
Christopher Browne
(416) 673-4124 (land)

Tang, Jason

2005-06-15, 11:25 am

> > ..then it goes quiet. Tried doing an insert, but not a sausage
>=20
> Hmm. Maybe the logging isn't turned high enough :-).
>=20
> Make sure the slon processes have "-d2", maybe?

Umm.. sorry.. my bad. Too much caffeine and brain tired.

Not that sure how to interpret this. Slave stuff I would have a guess is
getting something back from master?

Jase

MASTER
DEBUG2 remoteWorkerThread_2
: Received event 2,16 SYNC
DEBUG2 remoteWorkerThread_2
: SYNC 16 processing
DEBUG2 remoteWorkerThread_2
: no sets need syncing for this event
DEBUG2 syncThread: new sl_action_seq 1 - SYNC 42
DEBUG2 localListenThread: Received event 1,42 SYNC
DEBUG2 remoteWorkerThread_2
: forward confirm 1,42 received by 2
DEBUG2 remoteListenThread_2
: queue event 2,17 SYNC
DEBUG2 remoteWorkerThread_2
: Received event 2,17 SYNC
DEBUG2 remoteWorkerThread_2
: SYNC 17 processing
DEBUG2 remoteWorkerThread_2
: no sets need syncing for this event

SLAVE
DEBUG2 remoteWorkerThread_1
: syncing set 1 with 16 table(s) from
provider 1
DEBUG2 remoteHelperThread_1
_1: 0.004 seconds delay for first row
DEBUG2 remoteHelperThread_1
_1: 0.005 seconds until close cursor
DEBUG2 remoteWorkerThread_1
: new sl_rowid_seq value: 1000000000067786
DEBUG2 remoteWorkerThread_1
: SYNC 41 done in 0.030 seconds
DEBUG2 syncThread: new sl_action_seq 1 - SYNC 16
DEBUG2 localListenThread: Received event 2,16 SYNC
DEBUG2 remoteWorkerThread_1
: forward confirm 2,16 received by 1
DEBUG2 remoteListenThread_1
: queue event 1,42 SYNC
DEBUG2 remoteWorkerThread_1
: Received event 1,42 SYNC
DEBUG2 remoteWorkerThread_1
: SYNC 42 processing
DEBUG2 remoteWorkerThread_1
: syncing set 1 with 16 table(s) from
provider 1
DEBUG2 remoteHelperThread_1
_1: 0.004 seconds delay for first row
DEBUG2 remoteHelperThread_1
_1: 0.005 seconds until close cursor
DEBUG2 remoteWorkerThread_1
: new sl_rowid_seq value: 1000000000067786
DEBUG2 remoteWorkerThread_1
: SYNC 42 done in 0.029 seconds

Christopher Browne

2005-06-15, 1:25 pm

"Tang, Jason" <Jason.Tang-EbOMXLyeCfLY0TyS/+Ba5Q@public.gmane.org> writes:
>
> Umm.. sorry.. my bad. Too much caffeine and brain tired.
>
> Not that sure how to interpret this. Slave stuff I would have a guess is
> getting something back from master?
>
> Jase
>
> MASTER
> DEBUG2 remoteWorkerThread_2
: Received event 2,16 SYNC
> DEBUG2 remoteWorkerThread_2
: SYNC 16 processing
> DEBUG2 remoteWorkerThread_2
: no sets need syncing for this event
> DEBUG2 syncThread: new sl_action_seq 1 - SYNC 42
> DEBUG2 localListenThread: Received event 1,42 SYNC
> DEBUG2 remoteWorkerThread_2
: forward confirm 1,42 received by 2
> DEBUG2 remoteListenThread_2
: queue event 2,17 SYNC
> DEBUG2 remoteWorkerThread_2
: Received event 2,17 SYNC
> DEBUG2 remoteWorkerThread_2
: SYNC 17 processing
> DEBUG2 remoteWorkerThread_2
: no sets need syncing for this event

Exactly what I'd expect...

> SLAVE
> DEBUG2 remoteWorkerThread_1
: syncing set 1 with 16 table(s) from
> provider 1
> DEBUG2 remoteHelperThread_1
_1: 0.004 seconds delay for first row
> DEBUG2 remoteHelperThread_1
_1: 0.005 seconds until close cursor
> DEBUG2 remoteWorkerThread_1
: new sl_rowid_seq value: 1000000000067786
> DEBUG2 remoteWorkerThread_1
: SYNC 41 done in 0.030 seconds
> DEBUG2 syncThread: new sl_action_seq 1 - SYNC 16
> DEBUG2 localListenThread: Received event 2,16 SYNC
> DEBUG2 remoteWorkerThread_1
: forward confirm 2,16 received by 1
> DEBUG2 remoteListenThread_1
: queue event 1,42 SYNC
> DEBUG2 remoteWorkerThread_1
: Received event 1,42 SYNC
> DEBUG2 remoteWorkerThread_1
: SYNC 42 processing
> DEBUG2 remoteWorkerThread_1
: syncing set 1 with 16 table(s) from
> provider 1
> DEBUG2 remoteHelperThread_1
_1: 0.004 seconds delay for first row
> DEBUG2 remoteHelperThread_1
_1: 0.005 seconds until close cursor
> DEBUG2 remoteWorkerThread_1
: new sl_rowid_seq value: 1000000000067786
> DEBUG2 remoteWorkerThread_1
: SYNC 42 done in 0.029 seconds

Exactly what I'd expect if things are working properly...

If you make changes on node 1, I'd expect them to propagate to node 2
fairly promptly.

This looks like things look on a system that's working AOK...
--
"cbbrowne","@","ca.afilias.info"
<http://dev6.int.libertyrms.com/>
Christopher Browne
(416) 673-4124 (land)

Sponsored Links