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 <wun...@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 <wun...@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 <anith...@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 <daire...@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 >>>> wun...@wunderwood.org >>>> >>>> >>>> >>>> >> >> -- >> Walter Underwood >> wun...@wunderwood.org >> >> >> >> -- Walter Underwood wun...@wunderwood.org
