Hi Erick, Your comment does not reflect on the Jira.
I also updated the MERGEINDEXES documentation ( https://cwiki.apache.org/confluence/display/solr/Merging+Indexes ) to reflect that the WAR is pre-extracted from Solr 5.3 onwards. On Thu, Sep 10, 2015 at 5:39 AM, Erick Erickson <[email protected]> wrote: > Hmmm...... It'd be great to have this documented! > > I gave this a quick shot just to see if it'd do what I'd expect and > it's not actually that hard: > > 0> created the "techproducts" non-solr-cloud collection > 1> shut down Solr > 2> moved the entire directory "somewhere else", not in the Solr tree > to simulate, say, bringing it over from some other machine. > 3> brought up ZK and pushed the configuration file up > 4> started SolrCloud (nothing is in it as you'd expect) > 5> created a new collection with the config from step <3> (name irrelevant) > 6> shut down the cloud > 7> Copied just the _contents_ of the index directory from step <0> to > the index directory created in <5> > 8> restarted SolrCloud > > And all was well. > > I also tried just creating a new collection (1 shard) and using > MERGEINDEXES with the indexDir option which also worked. I think I > like that a little better, there are fewer places to mess things up, > and it doesn't require bouncing SolrCloud. The first time I tried it I > didn't manage to issue the commit, so that should be called out. Also > should call out checking that the doc count is right since if a person > gets nervous and issues the merge N times you have Nx the docs... > > You'd want ADDREPLICAs once you were satisfied you'd moved the index > correctly of course. And hope that the config you pushed up was > actually OK. Perhaps something here about just moving the relevant > parts of schema.xml rather than the whole (old) config dir? Or maybe > even proofing things out on 5x first? > > Of course, all this assuming you couldn't just re-index fresh ;). > > FWIW, > Erick > > > > On Wed, Sep 9, 2015 at 4:31 PM, Shawn Heisey (JIRA) <[email protected]> > wrote: > > > > [ > https://issues.apache.org/jira/browse/SOLR-8027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14737799#comment-14737799 > ] > > > > Shawn Heisey commented on SOLR-8027: > > ------------------------------------ > > > > I can try out some things tonight when I get home, assuming the honeydew > list is not extreme. > > > >> Reference guide instructions for converting an existing install to > SolrCloud > >> > ---------------------------------------------------------------------------- > >> > >> Key: SOLR-8027 > >> URL: https://issues.apache.org/jira/browse/SOLR-8027 > >> Project: Solr > >> Issue Type: Improvement > >> Components: documentation > >> Reporter: Shawn Heisey > >> > >> I have absolutely no idea where to begin with this, but it's a definite > hole in our documentation. I'd like to have some instructions that will > help somebody convert a non-cloud install to SolrCloud. Ideally they would > start with a typical directory structure with one or more cores and end > with cores named foo_shardN_replicaM. > >> As far as I know, Solr doesn't actually let non-cloud cores coexist > with cloud cores. I once tried to create a non-cloud core on a cloud > install, and couldn't do it. > > > > > > > > -- > > This message was sent by Atlassian JIRA > > (v6.3.4#6332) > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- Regards, Varun Thacker
