Slony I - Problem dropping a set from pgAdmin
От | Glyn Astill |
---|---|
Тема | Slony I - Problem dropping a set from pgAdmin |
Дата | |
Msg-id | 478CDB68.6000100@seetickets.com обсуждение исходный текст |
Список | pgadmin-support |
<pre><tt>Hi chaps, I've noticed a problem as described below with regards to adding replication sets from within pgAdmin. I originally posted on the slony I general list, and Christopher Browne suggested I ask you guys. I set up a replication cluster using the pgAdmin scripts, and added a replication set with some tables and sequences in it (table /sequence Ids 1 - 4). I've kept the Id numbers the same as the table Ids. Then I added another set (Id 2), and added a table and a sequence with Id 5. In my slony log I get the error: "remoteWorkerThread_1: node -1 not found in runtime configuration" Does anyone know what causes the error above? I've read that it indicates slony had a problem at a point whilst subscribing so it flipped the node number to -1 to stop any further steps happening, however this doesn't help me track down what caused it. No "drop set" option seems to exist from with pgAdmin (although I'm pretty sure I saw it once - are their criteria that make it appear?), so I did a "DROP SET ( ID=2, ORIGIN=1 );" using slonik on the origin, and the set was removed from the origin, but it's still visible (using pgadmin) on the subscriber (I have restarted the slons). I notice this error occours periodically now in the slony logs, so it seems the subscriber is trying to subscribe it? E.g. ------------------------------------------------------ 2008-01-15_144529 GMT DEBUG2 syncThread: new sl_action_seq 1 - SYNC 38491 2008-01-15_144533 GMT DEBUG1 copy_set 2 2008-01-15_144533 GMT ERROR remoteWorkerThread_1: node -1 not found in runtime configuration 2008-01-15_144533 GMT WARN remoteWorkerThread_1: data copy for set 2 failed - sleep 60 seconds WARNING: there is no transaction in progress ------------------------------------------------------ How do I remove this set from the subscriber? I've had this happen before. Removing the cluster and setting it up again resolves the problem, however once we are in a production environment I can't go dropping the whole cluster and replicating all the tables from scratch when it happens. Any pointers would be greatly appreciated Glyn</tt></pre><div class="moz-signature">-- <br /><p><font face="Arial" size="2">Glyn Astill<br /> Programmer<br /><b>See</b><tableborder="0"><tbody><tr><td><font face="Arial" size="2">Direct</font></td><td><font face="Arial" size="2">01159129 135</font></td></tr><tr><td><font face="Arial" size="2">IT Helpdesk</font></td><td><font face="Arial" size="2">01159129 120</font></td></tr><tr><td><font face="Arial" size="2">Fax</font></td><td><font face="Arial" size="2">01159129 247</font></td></tr></tbody></table><a class="moz-txt-link-abbreviated" href="http://www.seetickets.com">www.seetickets.com</a></font></div>
В списке pgadmin-support по дате отправления: