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
