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 > > > >
