Slony1 PostgreSQL Replication - example of reconfigure

Author

example of reconfigure

Sebastian Kühner

2005-09-08, 1:26 pm

Hello,

Does anyone of you have an example to reconfigure node 1 after a failover? I
read that you have to setup it as a slave. How do I setup a slave? Is there
any command for that?

Thanks!

Sebastian

Christopher Browne

2005-09-08, 8:24 pm

Sebastian K=FChner <skuehner- W+yTvUamF4rQT0dZR+Al
fA@public.gmane.org> writes:
> Does anyone of you have an example to reconfigure node 1 after a failover=
? I
> read that you have to setup it as a slave. How do I setup a slave? Is the=
re
> any command for that?

How did you set up all the other nodes that are subscribing???

Recreating the node involves...

1. Dropping the former node 1 from the cluster's configuration

DROP NODE ();

2. Dropping Slony-I config from that node

UNINSTALL NODE ();

3. Creating the node afresh, just like any new node

STORE NODE ();
STORE PATH (); ### to indicate how it is to communicate
STORE LISTEN (); ### needful before version 1.1.0...

4. Presumably, at this point, you already have replication sets
operating, and just need to tell the new node to subscribe
to them.

SUBSCRIBE SET ();

There appears to be some possible confusion if node #1 gets re-used;
it's not clear why, though some suspicion lies in the fact that Slonik
request often default to be passed via "node #1."

I'd be inclined to set up any cluster I create to NOT have a node #1
as a result.
--=20
let name=3D"cbbrowne" and tld=3D"ca.afilias.info" in name ^ "@" ^ tld;;
<http://dev6.int.libertyrms.com/>
Christopher Browne
(416) 673-4124 (land)

Sebastian Kühner

2005-09-08, 8:24 pm

Ok,

I thought there's an easier way. So I uninstall all nodes I made
(uninstall.sh), change the server IPs of the "original" cluster_setup.sh =
(so
that the slave is the master now), restart slon and make a new subscribe.=
sh
(also with changed server IPs).

Then switchover.sh...

It's working good... well, failover seems a little bit complicated, but I
hope that it never will happen.

Thanks!

Sebastian

----- Original Message -----=20
From: "Christopher Browne" <cbbrowne-swQf4SbcV9C7WVzo/KQ3Mw@public.gmane.org>
To: "Sebastian K=FChner" <skuehner- W+yTvUamF4rQT0dZR+Al
fA@public.gmane.org>
Cc: <slony1-general- AuKwsB3Fm+ugFIWk8tvy
RWD2FQJk+8+b@public.gmane.org>
Sent: Thursday, September 08, 2005 3:59 PM
Subject: Re: [Slony1-general] example of reconfigure

Sebastian K=FChner <skuehner- W+yTvUamF4rQT0dZR+Al
fA@public.gmane.org> writes:
> Does anyone of you have an example to reconfigure node 1 after a failov=
er?
I
> read that you have to setup it as a slave. How do I setup a slave? Is
there

> any command for that?

How did you set up all the other nodes that are subscribing???

Recreating the node involves...

1. Dropping the former node 1 from the cluster's configuration

DROP NODE ();

2. Dropping Slony-I config from that node

UNINSTALL NODE ();

3. Creating the node afresh, just like any new node

STORE NODE ();
STORE PATH (); ### to indicate how it is to communicate
STORE LISTEN (); ### needful before version 1.1.0...

4. Presumably, at this point, you already have replication sets
operating, and just need to tell the new node to subscribe
to them.

SUBSCRIBE SET ();

There appears to be some possible confusion if node #1 gets re-used;
it's not clear why, though some suspicion lies in the fact that Slonik
request often default to be passed via "node #1."

I'd be inclined to set up any cluster I create to NOT have a node #1
as a result.
--=20
let name=3D"cbbrowne" and tld=3D"ca.afilias.info" in name ^ "@" ^ tld;;
<http://dev6.int.libertyrms.com/>
Christopher Browne
(416) 673-4124 (land)

Jim Archer

2005-09-09, 3:24 am

> Recreating the node involves...
>
> 1. Dropping the former node 1 from the cluster's configuration
>
> DROP NODE ();
>
> 2. Dropping Slony-I config from that node
>
> UNINSTALL NODE ();

It seems that the DROP NORE() command may be a superset of UNINSTALL
NODE(). After running ROP NODE, the slony specific schema is removed fro=
m
the node and the database is unlocked and can be modified by local users.

Is there another reason we need to call UNINSTALL NODE() after DROP NODE(=
)?

Thanks...

Jim Archer

2005-09-09, 3:24 am

Christopher Browne said:

> 3. Creating the node afresh, just like any new node
>
> STORE NODE ();
> STORE PATH (); ### to indicate how it is to communicate
> STORE LISTEN (); ### needful before version 1.1.0...
>
> 4. Presumably, at this point, you already have replication sets
> operating, and just need to tell the new node to subscribe
> to them.
>
> SUB**SCRIBE SET ();
>
> There appears to be some possible confusion if node #1 gets re-used;
> it's not clear why, though some suspicion lies in the fact that Slonik
> request often default to be passed via "node #1."
>
> I'd be inclined to set up any cluster I create to NOT have a node #1
> as a result.

I tried this as well, as a followup to my troubles from last night. I
don't have any node numbered 1 anywhere in my cluster, which has 1
provides, 2 subscribers and no forwarders. This is Slony 1.1 and
PostgreSQL 7.4.

The slonik commands all ran fine and the new node got the schema installe=
d
on it. I then started the slon daemon for the new node. This time I
lowered the log level a bit and I saw the error. The slon log contains:

2005-09-08 23:06:43 EDT [29532] DEBUG1 copy_set 1
2005-09-08 23:06:43 EDT [29532] DEBUG1 remoteWorkerThread_2
02: connected
to provider DB
2005-09-08 23:06:43 EDT [29532] WARN remoteWorkerThread_2
02:
transactions earlier than XID 1177475 are still in progress
2005-09-08 23:06:43 EDT [29532] WARN remoteWorkerThread_2
02: data copy
for set 1 failed - sleep 60 seconds

..
..
..

2005-09-08 23:11:43 EDT [29532] DEBUG1 copy_set 1
2005-09-08 23:11:43 EDT [29532] DEBUG1 remoteWorkerThread_2
02: connected
to provider DB
2005-09-08 23:11:43 EDT [29532] WARN remoteWorkerThread_2
02:
transactions earlier than XID 1177475 are still in progress
2005-09-08 23:11:43 EDT [29532] WARN remoteWorkerThread_2
02: data copy
for set 1 failed - sleep 60 seconds

It seems to think that there is a backlog of transactions it is waiting
for, but I don't understand why, since the node is brand new. Also, the
XID does not change, so that seems to be an indication that no
transactions are being processed.

Can someone please tell me what I did wrong?

Thanks very much...

Jim

cbbrowne-swQf4SbcV9C7WVzo/KQ3Mw@public.gmane.org

2005-09-09, 9:27 am

> Christopher Browne said:

>
>
> I tried this as well, as a followup to my troubles from last night. I
> don't have any node numbered 1 anywhere in my cluster, which has 1
> provides, 2 subscribers and no forwarders. This is Slony 1.1 and
> PostgreSQL 7.4.
>
> The slonik commands all ran fine and the new node got the schema instal=
led
> on it. I then started the slon daemon for the new node. This time I
> lowered the log level a bit and I saw the error. The slon log contains=
:
>
> 2005-09-08 23:06:43 EDT [29532] DEBUG1 copy_set 1
> 2005-09-08 23:06:43 EDT [29532] DEBUG1 remoteWorkerThread_2
02: connecte=
d
> to provider DB
> 2005-09-08 23:06:43 EDT [29532] WARN remoteWorkerThread_2
02:
> transactions earlier than XID 1177475 are still in progress
> 2005-09-08 23:06:43 EDT [29532] WARN remoteWorkerThread_2
02: data cop=
y
> for set 1 failed - sleep 60 seconds
>
> .
> .
> .
>
> 2005-09-08 23:11:43 EDT [29532] DEBUG1 copy_set 1
> 2005-09-08 23:11:43 EDT [29532] DEBUG1 remoteWorkerThread_2
02: connecte=
d
> to provider DB
> 2005-09-08 23:11:43 EDT [29532] WARN remoteWorkerThread_2
02:
> transactions earlier than XID 1177475 are still in progress
> 2005-09-08 23:11:43 EDT [29532] WARN remoteWorkerThread_2
02: data cop=
y
> for set 1 failed - sleep 60 seconds
>
>
> It seems to think that there is a backlog of transactions it is waiting
> for, but I don't understand why, since the node is brand new. Also, th=
e
> XID does not change, so that seems to be an indication that no
> transactions are being processed.
>
> Can someone please tell me what I did wrong?

There's nothing "wrong" that you have done.

The problem is that Slony-I can't start until that old transaction that
may predate the installation of Slony-I components completes.

If you peek in at pg_locks and/or pg_stat_activity, you'll presumably see
that some transaction is under way (namely #1177475, though that number
may not be easy to see).

Kill that connection and the floodgates will open :-).

Jim Archer

2005-09-09, 1:25 pm

Jim Archer

2005-09-10, 8:24 pm

cbbrowne-swQf4SbcV9C7WVzo/KQ3Mw@public.gmane.org said:

> The problem is that Slony-I can't start until that old transaction that
> may predate the installation of Slony-I components completes.
>
> If you peek in at pg_locks and/or pg_stat_activity, you'll presumably s=
ee
> that some transaction is under way (namely #1177475, though that number
> may not be easy to see).
>
> Kill that connection and the floodgates will open :-).

I just spent some time adding a fourth node to my test cluster. I had
this problem, I noticed that the pid and txid of the offending transactio=
n
kept changing. Finally, I killed all 4 slon daemons, restarted postgres
on the new node, restarted the slons and the problem went away.

Are these transactions being caused by the other slons that service the
other nodes? I had shutdown the one that serviced the new node many
times, and restarted postgres many times, but it was not until I killed
all the slons that I was able to get past this.

Jim

Sponsored Links