The most straightforward way would be to stop/offline the entire cluster, move the existing location, update the config and reload the cluster.
If you want to avoid having the whole cluster down though, you can do this one or two nodes at a time. The key is to note that you can move the orphaned data after you've update the config. So, in this approach, you can update the config over the whole cluster, then once that's done, go back to each node in turn, offline it, move the data, then bring it back online, then move to the next node. The biggest problem you'll have here is that you'll wind up with conflicting bucket ids, so when you move the data, you'll have to check and rename the old buckets with new non-conflicting ids numbers
You could also just cheat a bit. You're not supposed to have indexes.conf differerent on different nodes, but it's actually probably okay since it would only be temporary. Go to each node, take it offline, stick in a config in a new temporary app that overrides the default index location, move the buckets, start up the node. Repeat for each node. Then, when you're done, update the master config and push it out. Then, at some point in the future, go remove the temporary app. No rush, since the effective configuration you have with and without the app is identical, so you shouldn't have any run-time problems. But you should nevertheless remove it because in the long run you don't want to have the possibility of inconsistent local configs.
... View more
