To add to this, not sure of solr cloud uses it, but you're going to want to destroy the wrote.lock file as well
> On Aug 1, 2017, at 9:31 PM, Shawn Heisey <apa...@elyograg.org> wrote: > >> On 8/1/2017 7:09 PM, Erick Erickson wrote: >> WARNING: what I currently understand about the limitations of AWS >> could fill volumes so I might be completely out to lunch. >> >> If you ADDREPLICA with the new replica's data residing on the new EBS >> volume, then wait for it to sync (which it'll do all by itself) then >> DELETEREPLICA on the original you'll be all set. >> >> In recent Solr's, theres also the MOVENODE collections API call. > > I did consider mentioning that as a possible way forward, but I hate to > rely on special configurations with core.properties, particularly if the > newly built replica core instanceDirs aren't in the solr home (or > coreRootDirectory) at all. I didn't want to try and explain the precise > steps required to get that plan to work. I would expect to need some > arcane Collections API work or manual ZK modification to reach a correct > state -- steps that would be prone to error. > > The idea I mentioned seemed to me to be the way forward that would > require the least specialized knowledge. Here's a simplified stating of > the steps: > > * Mount the new volume somewhere. > * Use multiple rsync passes to get the data copied. > * Stop Solr. > * Do a final rsync pass. > * Unmount the original volume. > * Remount the new volume in the original location. > * Start Solr. > > Thanks, > Shawn >
