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 22:34:44 GMT
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




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