lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Walter Underwood <wun...@wunderwood.org>
Subject Re: Sharing index amongst multiple nodes
Date Sat, 06 Apr 2013 23:09:41 GMT
In Solr Cloud, a document is indexed on the shard leader. The replicas in that shard get the
document and add it to their indexes. There is some indexing that happens on the replicas,
but that is managed by Solr.

wunder

On Apr 6, 2013, at 3:58 PM, Furkan KAMACI wrote:

> Hi Walter;
> 
> Thanks for your explanation. You said "Indexing happens on one Solr
> server". Is it true even for SolrCloud?
> 
> 
> 2013/4/7 Walter Underwood <wunder@wunderwood.org>
> 
>> Indexing happens on one Solr server. After a commit, the documents are
>> searchable. In Solr 4, there is a "soft commit", which makes the documents
>> searchable, but does not create on-disk indexes.
>> 
>> Solr replication copies the committed indexes to another Solr server.
>> 
>> Solr Cloud uses a transaction log to make documents available before a
>> hard commit.
>> 
>> Solr does not have rollback. A commit succeeds or fails. After it
>> succeeds, there is no going back.
>> 
>> wunder
>> 
>> On Apr 6, 2013, at 3:08 PM, Furkan KAMACI wrote:
>> 
>>> Hi Walter;
>>> 
>>> I am new to Solr and digging into code to understand it. I think that
>> when
>>> indexer copies indexes, before the commit it is unsearchable.
>>> 
>>> Where exactly that commit occurs at code and can I say that: rollback
>>> something because I don't want that indexes (reason maybe anything else,
>>> maybe I will decline some indexes(index filtering) because of the
>> documents
>>> they points. Is it possible?
>>> 
>>> 
>>> 
>>> 2013/4/7 Walter Underwood <wunder@wunderwood.org>
>>> 
>>>> This is precisely how Solr replication works. It copies the indexes then
>>>> does a commit.
>>>> 
>>>> wunder
>>>> 
>>>> On Apr 6, 2013, at 2:40 PM, Furkan KAMACI wrote:
>>>> 
>>>>> Hi Daire Mac MathĂșna;
>>>>> 
>>>>> If there is a way copying one Solr's indexes into another Solr
>> instance,
>>>>> this may also solve the problem. Somebody generates indexes and some
of
>>>>> other instances could get a copy of them. At synchronizing process you
>>>> may
>>>>> eliminate some of indexes at reader instance. So you can filter
>> something
>>>>> to become unsearchable. *This may not be efficient and good thing and
>>>> maybe
>>>>> solved with built-in functionality somehow.* However I think somebody
>> may
>>>>> need that mechanism.
>>>>> 
>>>>> 
>>>>> 2013/4/6 Amit Nithian <anithian@gmail.com>
>>>>> 
>>>>>> I don't understand why this would be more performant.. seems like
it'd
>>>> be
>>>>>> more memory and resource intensive as you'd have multiple
>> class-loaders
>>>> and
>>>>>> multiple cache spaces for no good reason. Just have a single core
with
>>>>>> sufficiently large caches to handle your response needs.
>>>>>> 
>>>>>> If you want to load balance reads consider having multiple physical
>>>> nodes
>>>>>> with a master/slaves or SolrCloud.
>>>>>> 
>>>>>> 
>>>>>> On Sat, Apr 6, 2013 at 9:21 AM, Daire Mac MathĂșna <dairemac@gmail.com
>>>>>>> wrote:
>>>>>> 
>>>>>>> Hi. Wat are the thoughts on having multiple SOLR instances i.e.
>>>> multiple
>>>>>>> SOLR war files, sharing the same index (i.e. sharing the same
>>>> solr_home)
>>>>>>> where only one SOLR instance is used for writing and the others
for
>>>>>>> reading?
>>>>>>> 
>>>>>>> Is this possible?
>>>>>>> 
>>>>>>> Is it beneficial - is it more performant than having just one
solr
>>>>>>> instance?
>>>>>>> 
>>>>>>> How does it affect auto-commits i.e. how would the read nodes
know
>> the
>>>>>>> index has been changed and re-populate cache etc.?
>>>>>>> 
>>>>>>> Sole 3.6.1
>>>>>>> 
>>>>>>> Thanks.
>>>>>>> 
>>>>>> 
>>>> 
>>>> --
>>>> Walter Underwood
>>>> wunder@wunderwood.org
>>>> 
>>>> 
>>>> 
>>>> 
>> 
>> --
>> Walter Underwood
>> wunder@wunderwood.org
>> 
>> 
>> 
>> 

--
Walter Underwood
wunder@wunderwood.org




Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message