lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jamie Johnson <jej2...@gmail.com>
Subject Re: Solr Lucene Index Version
Date Thu, 08 Dec 2011 01:39:08 GMT
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 <markrmiller@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
>
>
>
>
>
>
>
>
>
>
>

Mime
View raw message