Thanks Kurt. We had one sstable from a cf of ours. I am actually running a repair on that cf now and then plan to try and join the additional nodes as you suggest. I deleted the opscenter corrupt sstables as well but will not bother repairing that before adding capacity.
Been keeping an eye across all nodes for corrupt exceptions - so far no new occurrences. Thanks again. -B On Sun, Aug 13, 2017 at 17:52 kurt greaves <k...@instaclustr.com> wrote: > > > On 14 Aug. 2017 00:59, "Brian Spindler" <brian.spind...@gmail.com> wrote: > > Do you think with the setup I've described I'd be ok doing that now to > recover this node? > > The node died trying to run the scrub; I've restarted it but I'm not sure > it's going to get past a scrub/repair, this is why I deleted the other > files as a brute force method. I think I might have to do the same here > and then kick off a repair if I can't just replace it? > > is it just opscenter keyspace that has corrupt sstables? if so I wouldn't > worry about repairing too much. If you can get that third node in C to join > I'd say your best bet is to just do that until you have enough nodes in C. > Dropping and increasing RF is pretty risky on a live system. > > It sounds to me like you stand a good chance of getting the new nodes in C > to join so I'd pursue that before trying anything more complicated > > > Doing the repair on the node that had the corrupt data deleted should be > ok? > > Yes. as long as you also deleted corrupt SSTables on any other nodes that > had them. > -- -Brian
