The core admin MERGEINDEXES will work for you I'm pretty sure. You
copy the NRT index over to the all-the-time box. MERGEINDEXES just
takes the path to the index you want to add to the existing core.
Note the warnings in the reference guide about taking care that the
indexes aren't changing and committing at the very end of the
operation.
I suspect this is one of the cases where optimizing is called for, I
don't believe the MERGEINDEXES call triggers any kind of segment
merging, and since your all-the-time index isn't getting incremental
updates (I'm assuming), there's no event to trigger incremental
merges.
Best
Erick
On Fri, Apr 17, 2015 at 2:24 AM, ariya bala <ariya...@gmail.com> wrote:
> Hi Norgorn,
>
> I think there is no ready-made tool out of the box, but you have the spare
> parts in the MapreduceIndexerTool :-)
> With little effort you can decouple the index merging component from
> MRIndexerTool and use based on the needs.
> I did the same.
>
> On Fri, Apr 17, 2015 at 10:40 AM, Norgorn <lsunnyd...@mail.ru> wrote:
>
>> Thank you for the reply.
>> Out schema is:
>> 1) Index real-time (on separate machine).
>> 2) NRT index becomes large.
>> 3) Copy NRT index on other machine.
>> 3) Merge NRT-made indexes with large ("all-the-time") index.
>> 4) Remove NRT index (until now it was available for searching).
>>
>> At the end we have big, optimized index with data of all the time.
>> And we'r ready to index more data and indexing will be fast.
>>
>> Excuse me, if I'm describing unclearly.
>>
>> About optimization - indexing with low merge-factor results in lot of
>> segments, which results in slow search, so we have to make it.
>>
>>
>>
>>
>>
>> --
>> View this message in context:
>> http://lucene.472066.n3.nabble.com/Merge-indexes-in-MapReduce-tp4200106p4200346.html
>> Sent from the Solr - User mailing list archive at Nabble.com.
>>
>
>
>
> --
> *Ariya *
