Thanks Erick, i think i then will try to setup 6 slaves and configure them nicely.
Daniel On Fri, Jan 20, 2012 at 5:38 PM, Erick Erickson <erickerick...@gmail.com>wrote: > There will be some increase pressure on your resources when replication > happens to the slaves. That said, you can also allocate resources > differently > between the two. For instance, you do not need any memory for the RAMBuffer > on the slaves since you're not indexing. On the master, you don't need any > caches to speak of (e.g. filterCache) because you're not doing any > searching. > > And let's assume you're pushing structured documents, e.g. Word or PDF docs > to Solr. Those are resource-intensive things to parse and index so wouldn't > compete with search requests on the slaves. > > Having an index big enough that it requires sharding is almost a sure sign > that > trying to index and search on the same box containing the shard is going > to cause trouble. > > Bottom line: you have many fewer options for tuning the search process. > Usually > people only have relatively small indexes on a single box for both > searching and > indexing. > > Best > Erick > > On Fri, Jan 20, 2012 at 5:45 AM, Daniel Brügge > <daniel.brue...@googlemail.com> wrote: > > Erick, > > > > yes, currently I have 6 shards, which accept writes and reads. Sometimes > I > > delete data from all 6 and try to balance them, fill them up > respectively, > > so they have approx. the same amount of data on it. So all 6 are 'in > > motion' somehow. I would like that the writing would take place more > often > > than now, but after a write the querying slows down, so I reduce writing > to > > every n hours. > > > > So I've thought maybe it would make sense to add 6 slave shards. But > what I > > don't know is, if the slave-shards also suffer after a replication and > the > > querying will take some time too. I had a master/slave setup before, but > > without sharding. So only one big master and one slave. And after a > > replication it took couple of minutes to get a proper performance. > > > > Daniel > > > > > > > > > > On Fri, Jan 20, 2012 at 3:05 AM, Erick Erickson <erickerick...@gmail.com > >wrote: > > > >> It's generally recommended that you do the indexing on the master > >> and searches on the slaves. In that case, firstSearcher and > >> newSearcher sections are irrelevant on the master and shouldn't > >> be there. > >> > >> I don't understand why you would need 5 more machines, are you > >> sharding? > >> > >> Best > >> Erick > >> > >> On Thu, Jan 19, 2012 at 7:25 AM, Daniel Brügge > >> <daniel.brue...@googlemail.com> wrote: > >> > Hi, > >> > > >> > I am currently running multiple Solr instances and often write data to > >> > them. I also query them. Both works fine right now, because I don't > have > >> so > >> > many search requests. For querying I recognized that the firstSearcher > >> and > >> > newSearcher static warming with one facet query really brings a > >> performance > >> > boost. But the downside is, that writing now is really slow. > >> > > >> > Does it make sense at all to place firstSearcher and newSearcher on a > >> Solr > >> > server, which get lot's of writes. Or is the best strategy to > introduce > >> > some slave server, where these event listeners are integrated, but to > >> keep > >> > them away from the master? > >> > > >> > The thing is, that I would need 6 additional Solr slaves, if I would > pick > >> > this approach. :) > >> > > >> > What do you think? > >> > > >> > Thanks. > >> > Daniel > >> >
