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
