On Thu, October 18, 2007 4:52 pm, Christopher Browne wrote:
> "Henry - Zen Search SA" <henry at zen.co.za> writes:
> Actually, no, I don't think you have "mucked things up further" at
> this point...
>
> That error message doesn't surprise me too much, based on the scenario
> you described.
>
> What I *think* would probably work to clean things up would be
> outlined thus:
>
> - On each node, clean out the configuration for table #121
>
>   - On the "master" node, where you had actually dropped the table,
>     this solely involves deleting the entry in sl_table.
>
>     e.g. - "delete from _db_cluster.sl_table where id = 121;"
>
>   - On other nodes, where the table hasn't been mucked with, you can
>     pretty cleanly drop the table from replication via:
>
>     select  _db_cluster.setdroptable_int(121);
>
>   Once one of those two actions has been taken everywhere, you can add
>   the table back to replication...
>
> - Make sure the table is present on all nodes
>
> - Submit slonik script consisting of:
>
>   CREATE SET for a new set
>   SET ADD TABLE to add your errant table to the new set
>   SUBSCRIBE SET as many times as needed to get the table replicating
>
> - Once replication is back working on that table...
>   Slonik MERGE SET will merge the new set into the old one so that
>   you don't have the complexity of extra replication sets in your
>   configuration


Great, that worked, thanks Christopher.   Looks like replication is back
online for this table!

Thank you very much.

Regards
Henry

--
Zen Search SA
http://zen.co.za/