Yeah I was actually hoping that some how I could use the replication handler to do this, fire up 1 shard, set another as a slave and see if it would replicate the index to it but obviously I'm not sure that would work either.
Something like this would be great too https://issues.apache.org/jira/browse/LUCENE-3491 On Wed, Dec 7, 2011 at 7:48 PM, Mark Miller <markrmil...@gmail.com> wrote: > Unfortunately, I think the the only silver bullet here, for pure Solr, is to > build a system that makes it possible to reindex somehow. > > On Dec 7, 2011, at 1:38 PM, Erik Hatcher wrote: > >> >> On Dec 7, 2011, at 13:20 , Shawn Heisey wrote: >> >>> On 12/6/2011 2:06 PM, Erik Hatcher wrote: >>>> I think the best thing that you could do here would be to lock in a >>>> version of Lucene (all the Lucene libraries) that you use with SolrCloud. >>>> Certainly not out of the realm of possibilities of some upcoming SolrCloud >>>> capability that requires some upgrading of Lucene though, but you may be >>>> set for a little while at least. >>> >>> I have no weight with the Lucene project, especially because I know very >>> little of its internals. >>> >>> If the code that handles each new index format were also able to read the >>> index format that preceded it, one could incrementally step forward from >>> revision to revision within trunk, running an optimize (forcedMerge?) at >>> each version to upgrade the index format. >> >> Shawn - that is the case with Lucene. The issue Jamie is bringing up is >> going from an *unreleased* snapshot of Lucene to a later *unreleased* >> snapshot of Lucene - and those types of guarantees aren't made across >> snapshots like this. >> >> > > - Mark Miller > lucidimagination.com > > > > > > > > > > >
