|
Home > Archive > Slony1 PostgreSQL Replication > January 2006 > The 1.1 "listen path problem"
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 |
The 1.1 "listen path problem"
|
|
| Christopher Browne 2006-01-24, 8:25 pm |
| Alan Hodgson wrote:
>On January 24, 2006 01:50 pm, Chris Browne <cbbrowne-HInyCGIudOg@public.gmane.org> wrote:
>
>
>
>What exactly was the nature of the listen path problem that wasn't going to
>be fixed in this version? Are we going to have to go back to manually
>specifying dozens of listen entries in order to be able to use PostgreSQL
>8.1?
>
>
>
This is documented fairly properly now in the FAQ...
The problem only comes up if you have a configuration with 4+ nodes, and
multiple subscription sets, where those subscription sets do not share
any nodes.
The problem is that, in that case, the listen paths wind up being
somewhat deficient, so that confirmations don't pass properly between
the disjoint subsets of nodes participating in each replication set.
Thus, you might have set #1, replicating from node 101 to node 102.
And you have set #2, replicating from node 201 to node 202.
Replication works fine with each set; it's just that confirmations don't
make it back, and so sl_log_1 never gets cleaned out :-(.
If you aren't using that sort of "disjoint set" pattern of replication,
then you shouldn't have a problem.
We're always building sets of nodes that are trees; it's not a problem,
with trees. The problem is when you have a forest of nonintersecting
trees...
>From the FAQ:
*Q: I am running Slony-I 1.1 and have a 4+ node setup where there are
two subscription sets, 1 and 2, that do not share any nodes. I am
discovering that confirmations for set 1 never get to the nodes
subscribing to set 2, and that confirmations for set 2 never get to
nodes subscribing to set 1. As a result, sl_log_1
<http://linuxfinances.info/info/table.sl-log-1.html> grows and grows and
is never purged. This was reported as Slony-I bug 1485
<http://gborg.postgresql.org/project...update.php?1485>.*
*A: * Apparently the code for |RebuildListenEntrie
s()| does not suffice
for this case.
| RebuildListenEntries
()| will be replaced in Slony-I version 1.2 with
an algorithm that covers this case.
In the interim, you'll want to manually add some sl_listen
<http://linuxfinances.info/info/table.sl-listen.html> entries using
STORE LISTEN(7) <http://linuxfinances.info/info/stmtstorelisten.html> or
|storeListen()|, based on the (apparently not as obsolete as we thought)
principles described in Section 8
<http://linuxfinances.info/info/listenpaths.html>.
| |
| Jim C. Nasby 2006-01-26, 8:23 pm |
| On Tue, Jan 24, 2006 at 06:07:53PM -0500, Christopher Browne wrote:
> Thus, you might have set #1, replicating from node 101 to node 102.
>
> And you have set #2, replicating from node 201 to node 202.
>
> Replication works fine with each set; it's just that confirmations don't
> make it back, and so sl_log_1 never gets cleaned out :-(.
>
> If you aren't using that sort of "disjoint set" pattern of replication,
> then you shouldn't have a problem.
Would simply subscribing all nodes to a table that never gets updated
fix this as well? ISTM that might be easier than fiddling with
listen_path...
--
Jim C. Nasby, Sr. Engineering Consultant jnasby-D/ iDPWeZeLdl57MIdRCFDg
@public.gmane.org
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
|
|
|
|
|