One thing to watch out for in splunkd.log on the CM when performing the removal is
02-11-2015 09:26:16.386 -0600 WARN CMMaster - did not schedule removal for peer=...
It would appear that perhaps a fsck or other activity on the peer prevented removal although the REST call returned a 200. In my case, when the peers were restarted, the damaged buckets began replicating again.
Making the same call a few times while watching for the absence of that error in splunkd.log did the trick for me.
... View more