|
Home > Archive > Slony1 PostgreSQL Replication > July 2005 > How to shoot yourself into foot when adding nodes
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
How to shoot yourself into foot when adding nodes
|
|
| Hannu Krosing 2005-07-07, 7:24 am |
| The following is aa warning to anyone attempting to add a node to slony
cluster
This happened on Slony 1.0.5
I have a cluster replicating several sets, and yesterday I tried to add
yet another node to it and to subscribe the new node to get set5 from
"node3" which was subscribing to the master node "node1".
I noticed that node3 was subscribing with forward=no, so I made a small
slonik script to set subscription to forward=yes. unfortunately I made a
small typo (or maybe a thinko) and also wrote the set id (5) as
provider, so that instead of subscribing to node1, node3 was now
subscribing to node5, which did not even have any of the tables in set5.
Later, when I noticed muy mistake, I was also change tha provider back
to node1, but I'm now missing the changes that had happened in between.
Is there any reason, why slony allows me to silently change also the
provider of a set subscription to a node that is neither master nor a
subscriber of that set ?
Or is this just a bug ?
Maybe it is even fixed in slony 1.1 ?
--
Hannu Krosing <hannu-7C/ iILuz2RdeoWH0uzbU5w@
public.gmane.org>
| |
| Jan Wieck 2005-07-07, 7:24 am |
| On 7/6/2005 5:47 PM, Hannu Krosing wrote:
> The following is aa warning to anyone attempting to add a node to slony
> cluster
>
> This happened on Slony 1.0.5
>
> I have a cluster replicating several sets, and yesterday I tried to add
> yet another node to it and to subscribe the new node to get set5 from
> "node3" which was subscribing to the master node "node1".
>
> I noticed that node3 was subscribing with forward=no, so I made a small
> slonik script to set subscription to forward=yes. unfortunately I made a
> small typo (or maybe a thinko) and also wrote the set id (5) as
> provider, so that instead of subscribing to node1, node3 was now
> subscribing to node5, which did not even have any of the tables in set5.
A quick glimpse over the code shows that there is in fact no such test
that would guard against that. Please add it as a bug report with the
hint that subscribeSet_int() must check that the provider itself is a
forwarding subscriber.
Jan
>
> Later, when I noticed muy mistake, I was also change tha provider back
> to node1, but I'm now missing the changes that had happened in between.
>
> Is there any reason, why slony allows me to silently change also the
> provider of a set subscription to a node that is neither master nor a
> subscriber of that set ?
>
> Or is this just a bug ?
>
> Maybe it is even fixed in slony 1.1 ?
>
>
--
#===================
====================
====================
===========#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#===================
====================
=========== JanWieck- bwPqjjyvM7QAvxtiuMwx
3w@public.gmane.org #
|
|
|
|
|