<html><body><div style="color:#000; background-color:#fff; font-family:times new roman, new york, times, serif;font-size:12pt"><div><span>Hi Christopher,</span></div><div><br><span></span></div><div><span>Thanks for your reply...</span></div><div><br><span></span></div><div><span>I will test your method and will let you know.<br></span></div><div><br></div> <div style="font-family: times new roman, new york, times, serif; font-size: 12pt;"> <div style="font-family: times new roman, new york, times, serif; font-size: 12pt;"> <div dir="ltr"> <font size="2" face="Arial"> <hr size="1"> <b><span style="font-weight:bold;">De :</span></b> Christopher Browne <cbbrowne@afilias.info><br> <b><span style="font-weight: bold;">À :</span></b> David TECHER <davidtecher@yahoo.fr> <br><b><span style="font-weight: bold;">Cc :</span></b> Slony Hackers <slony1-hackers@lists.slony.info> <br> <b><span style="font-weight: bold;">Envoyé le
:</span></b> Jeudi 16 février 2012 18h23<br> <b><span style="font-weight: bold;">Objet :</span></b> Re: [Slony1-hackers] Dropping table from one slave without subscribing again<br> </font> </div> <br>On Thu, Feb 16, 2012 at 6:41 AM, David TECHER <<a ymailto="mailto:davidtecher@yahoo.fr" href="mailto:davidtecher@yahoo.fr">davidtecher@yahoo.fr</a>> wrote:<br>> I had a look on Slony documentation at<br>> <a href="http://slony.info/documentation/1.2/dropthings.html" target="_blank">http://slony.info/documentation/1.2/dropthings.html</a> and I came to the<br>> conclusion<br>> that it shoud be possible to do it using the "old way"<br><br>This is, in an important sense, corrupting the cluster, because the<br>configuration of the cluster considers all of those tables to be<br>subscribed by all the nodes. If you need to do any switching around<br>of nodes (e.g. - moving master, or shuffling around subscriptions to<br>point to
different sources), the fact that sl_table+sl_set have one<br>picture of things, whilst the triggers have another, will make the<br>cluster mighty fragile.<br><br>What I would do in this case is to separate these few tables into a<br>separate replication set, and only replicate that set to certain<br>nodes.<br><br>That's easiest if you create the two sets in the beginning.<br><br>create set (id = 1, origin=1, comment = ' set for most of the tables<br>subscribed everywhere');<br>set add table (id = 1, set id = 1, ...)<br>set add table (id = 2, set id = 1, ...)<br><br>create set (id = 2, origin=1, comment='set for the tables that only<br>need to be replicated to a few nodes');<br>set add table (id = 20, set id = 2, ...)<br>set add table (id = 21, set id = 2, ...)<br><br>If you're doing "surgery" after the fact, that is, if you only have<br>set #1 with all the tables, what I would do is...<br><br>- Create the new set<br> create set (id = 2,
origin=1, comment='set for the tables that only<br>need to be replicated to a few nodes');<br><br>- Subscribe it everywhere that set #1 is subscribed. It has to have<br>*identical* subscriptions.<br> (Yes, it's empty at the moment. That's OK.)<br><br>e.g.:<br> subscribe set (id=2, provider=1, receiver=2, forward=yes);<br> subscribe set (id=2, provider=1, receiver=3, forward=yes);<br> subscribe set (id=2, provider=2, receiver=4, forward=yes);<br> subscribe set (id=2, provider=1, receiver=5, forward=yes);<br><br>Next, shift the tables that you want partially replicated into set #2<br> set move table (origin=1, id=40, new set=2);<br> set move table (origin=1, id=41, new set=2);<br><br>SET MOVE TABLE will refuse to shift the table to the new set unless<br>the subscription lists for the two sets are identical.<br><br>Once the tables are separated into the second set, you can remove the<br>subscriptions
for set #2 that aren't needed.<br><br>Thus, supposing those tables are only needed by nodes 2 and 3, but not<br>by nodes 4 or 5, you can drop the subscriptions:<br><br>unsubscribe set (id=2, receiver=4);<br>unsubscribe set (id=2, receiver=5);<br><br>That's the clean way to handle this.<br><br><br> </div> </div> </div></body></html>