Actually, I do have an idea what tool to use, bin/solr. But use at your own risk.
You can use 'bin/solr zk cp -r blah blah blah" to copy the entire tree down to somewhere local then copy it back up to a different place. Prior to Solr 6.6, however, this wouldn't work when copying from root so beware.... WARNING! This was never really intended to be a ZK backup/restore, I'd prefer any ZK tools if possible. It has worked to backup/restore ZK from '/'. Personally if I was trying to do any of this I'd set up a second ZK ensemble, transfer over and then point my Solr instances at that until I was sure things were working. Actually if at all possible I'd start over as Shawn suggests. Best, Erick On Tue, Sep 26, 2017 at 10:58 AM, Shawn Heisey <apa...@elyograg.org> wrote: > On 9/15/2017 10:23 AM, James Keeney wrote: >> However, I'm not sure how to switch the production cluster to explicitly >> reference the directory it currently uses. Do I need to setup the directory >> first? > > To set up a *new* cloud under a chroot, you do need to create the chroot > within the ZK database as described by the documentation link you > referenced. > > If you're trying to change an *existing* cloud to a chroot, then you're > going to have a lot more work, and I'm not sure that it's something I > would actually try to do. > > To move an existing cloud, you would to need to find a way to duplicate > all of the SolrCloud information currently in the root of the ZK > database to another copy under a chroot directory before you begin > changing Solr installs. If you don't do that, then there will be > nothing defined for the cloud -- no collections, shards, etc. The > information stored locally in each Solr instance is NOT enough to > automatically reconstruct a SolrCloud database in ZK. Some of the > information only exists in ZK. > > I honestly have no idea what kind of tools you could use to copy all the > ZK data. There are a number of tools available for connecting to ZK and > treating it like a filesystem, but I do not know if they are capable of > recursively copying entire pieces of the tree. It would be very time > consuming to manually recreate the structure, but you could certainly do > it that way. > > Because moving an existing cloud would be painful, a better option would > be to leave your existing cloud where it is (no chroot) and set up any > new clouds using a chroot so they won't interfere with the first one or > with each other. > > If you really want to have both clouds using chroot, you could > potentially rebuild the original cloud from scratch, and then manually > delete all the old Solr information at the root of ZK. > > Thanks, > Shawn >
