Thanks all for your commits.
I followed Shawn steps (rsync) cause everything on that volume (ZooKeeper,
Solr home and data) and everything went great.
On Sun, Aug 6, 2017 at 12:47 AM, Erick Erickson <erickerick...@gmail.com>
> bq: I was envisioning a scenario where the entire solr home is on the old
> volume that's going away. If I were setting up a Solr install where the
> large/fast storage was a separate filesystem, I would put the solr home
> (or possibly even the entire install) under that mount point. It would
> be a lot easier than setting dataDir in core.properties for every core,
> especially in a cloud install.
> Agreed. Nothing in what I said precludes this. If you don't specify
> then the index for a new replica goes in the default place, i.e. under
> your install
> directory usually. In your case under your new mount point. I usually don't
> recommend trying to take control of where dataDir points, just let it
> I only mentioned it so you'd be aware it exists. So if your new install
> is associated with a bigger/better/larger EBS it's all automatic.
> bq: If the dataDir property is already in use to relocate index data, then
> ADDREPLICA and DELETEREPLICA would be a great way to go. I would not
> expect most SolrCloud users to use that method.
> I really don't understand this. Each Solr replica has an associated
> dataDir whether you specified it or not (the default is relative to
> the core.properties file). ADDREPLICA creates a new replica in a new
> place, initially the data directory and index are empty. The new
> replica goes into recovery and uses the standard replication process
> to copy the index via HTTP from a healthy replica and write it to its
> data directory. Once that's done, the replica becomes live. There's
> nothing about dataDir already being in use here at all.
> When you start Solr there's the default place Solr expects to find the
> replicas. This is not necessarily where Solr is executing from, see
> the "-s" option in bin/solr start -s.....
> If you're talking about using dataDir to point to an existing index,
> yes that would be a problem and not something I meant to imply at all.
> Why wouldn't most SolrCloud users use ADDREPLICA/DELTEREPLICA? It's
> commonly used to more replicas around a cluster.
> On Fri, Aug 4, 2017 at 11:15 AM, Shawn Heisey <apa...@elyograg.org> wrote:
> > On 8/2/2017 9:17 AM, Erick Erickson wrote:
> >> Not entirely sure about AWS intricacies, but getting a new replica to
> >> use a particular index directory in the general case is just
> >> specifying dataDir=some_directory on the ADDREPLICA command. The index
> >> just needs an HTTP connection (uses the old replication process) so
> >> nothing huge there. Then DELETEREPLICA for the old one. There's
> >> nothing that ZK has to know about to make this work, it's all local to
> >> the Solr instance.
> > I was envisioning a scenario where the entire solr home is on the old
> > volume that's going away. If I were setting up a Solr install where the
> > large/fast storage was a separate filesystem, I would put the solr home
> > (or possibly even the entire install) under that mount point. It would
> > be a lot easier than setting dataDir in core.properties for every core,
> > especially in a cloud install.
> > If the dataDir property is already in use to relocate index data, then
> > ADDREPLICA and DELETEREPLICA would be a great way to go. I would not
> > expect most SolrCloud users to use that method.
> > Thanks,
> > Shawn