Brad Nicholson bnichols
Wed Mar 1 10:52:01 PST 2006
Marc G. Fournier wrote:

> On Wed, 1 Mar 2006, Brad Nicholson wrote:
>
>> Marc G. Fournier wrote:
>>
>>>
>>> What about the extra nodes that you indicate above I have to 
>>> create?  Will those disappear also?  Is there any 'clean up' I'll 
>>> need to do?
>>>
>> You are not creating an extra node, you are creating an extra set, 
>> and subscribing that set to an exisiting node.
>
>
> Sorry, maybe I mis-understood your earlier replay, but:
>
> =====
>
>> Now, I'm guessing right now, but PROVIDER/RECEIVER can "reuse" the 
>> ones that are already defined as part of the original replication 
>> set, I don't need to create new ones just for the temporary set, do I?
>
>
> These are on a set by set basis, the fact that they are defined for 
> another set is irrelevant.
>
> =====
>
> I may be mis-reading your reply here ...
>
> When I originally setup replication between the two nodes, I had to 
> INIT CLUSTER and STORE NODE for each side ... in my case, NODE 1 and 
> NODE 2 ... I take it that I can have multiple SETs per CLUSTER, 

Yes.

> but do I need to define a NODE 3 / NODE 4 for the temporary SET I need 
> to create, 

No.

> or can I use the existing NODE 1 / NODE 2 that are already created?  
> And, the respective paths created via STORE PATH?
>
You use 1 and 2.  The provider/reciever are for the sets, not the 
nodes.  The procedure that you'd want to follow is

1)Create set 999 on node1
2)Subscribe set 999 to node 2 (provider is node1, receiever is node 2)
3)Merge set 999 into set 1.  This will put the table from set 999 into 
set 1, and set 999 will be gone.

If you were to use node 3 and 4, I beleive the merge set would fail.  If 
memory serves me, the two sets have to have the same providers and 
recievers across all nodes before you can merge them.

-- 
Brad Nicholson  416-673-4106
Database Administrator, Afilias Canada Corp.





More information about the Slony1-general mailing list