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