Hello, This is not recommended because people typically don't want the load from indexing affect queries/user experience. If your numbers are low, then this may not be a big deal. If you already need to create a core on 2 machines, creating it on 3 doesn't seem a big deal. There is a slight conflict in what you wrote, which is that cores will be created frequently, which implies you will quickly have lots of cores vs. desire to have minimal hardware.
If it were up to me, I'd consider a weaker/cheaper master, and more slaves. Otis -- Solr & ElasticSearch Support http://sematext.com/ On Tue, Mar 5, 2013 at 12:46 PM, Sujatha Arun <suja.a...@gmail.com> wrote: > Hi Otis,Michael, > > Thanks for your input and suggestions . > > Yes, we were considering the sticky session for pagination and we are not > planning for having index on EBS > > I would like to understand why its not the recommended approach, can you > please explain? > > Till now we were having a single server for both Indexing and search > ,though this was on dedicated server and not on cloud. Indexing would > happen sequentially via a queue due to which commits would happen for only > one or at most 2 cores simultaneously. > > With Master /Slave approach I see that when a slave replicates form master > based on the poll time which I have defined in solr.xml file & depending on > the number of cores/webapp ,the replication and hence commit is going to > happen simultaneously for many cores increasing load on slave server. > > By having 2 slaves and one master - whenever we create a core,which > happens quite frequently we need to create this on 3 servers instead of > two , which has to done manually by running a script on each server.We have > requirement for adding cores per each customer. > > I do understand that hardware requirements for master can be quite > different [Lower memory /higher CPU/Cache setting in config /autowarming > etc ] from slave.But given that we will be Indexing sequentially and > having the same configuration in terms of memory and CPU/cache for both > master and slave,would this be a reasonable approach? > > Thanks&Regards, > Sujatha > > > > On Tue, Mar 5, 2013 at 9:10 PM, Michael Della Bitta < > michael.della.bi...@appinions.com> wrote: > > > If your index is on EBS, you'll see big iowait percentages when merges > > happen. > > > > I'm not sure what that's going to do to your master's ability to > > service requests. You should test. > > > > Alternatively, you might figure out the size of machine you need to > > index vs. the size of machine you need to service queries. They're > > very likely not the same, in which case, that may afford you the > > ability to have 2 slaves and 1 master in a similar budget. > > > > Also, once you've settled on an infrastructure, you should investigate > > buying reserved instances for a year. It will greatly reduce your > > costs. > > > > Michael Della Bitta > > > > ------------------------------------------------ > > Appinions > > 18 East 41st Street, 2nd Floor > > New York, NY 10017-6271 > > > > www.appinions.com > > > > Where Influence Isn’t a Game > > > > > > On Tue, Mar 5, 2013 at 8:59 AM, Sujatha Arun <suja.a...@gmail.com> > wrote: > > > Is there anything wrong with set up? > > > > > > On Tue, Mar 5, 2013 at 5:43 PM, Sujatha Arun <suja.a...@gmail.com> > > wrote: > > > > > >> Hi Otis, > > >> > > >> Since currently we are planning for only one slave due to cost > > >> considerations, can we have an ELB fronting the master and slave for > HA. > > >> > > >> 1. All index requests will go to the master . > > >> 2. Slave replicates from master . > > >> 3. Search request can go either to master /slave via ELB. > > >> > > >> is that resonable HA for search ? > > >> > > >> Regards > > >> Sujatha > > >> > > >> > > >> > > >> On Tue, Mar 5, 2013 at 5:12 PM, Otis Gospodnetic < > > >> otis.gospodne...@gmail.com> wrote: > > >> > > >>> Hi Sujatha, > > >>> > > >>> If I understand correctly, you will have only 1 slave (and 1 master), > > so > > >>> that's not really a HA architecture. You could manually turn master > > into > > >>> slave, but that's going to mean some down time... > > >>> > > >>> Otis > > >>> -- > > >>> Solr & ElasticSearch Support > > >>> http://sematext.com/ > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> On Tue, Mar 5, 2013 at 3:05 AM, Sujatha Arun <suja.a...@gmail.com> > > wrote: > > >>> > > >>> > Hi, > > >>> > > > >>> > We are planning to set up *2* *High-Memory Quadruple Extra Large > > >>> Instance > > >>> > *as > > >>> > master and slave for our multicore solr setup which has more than > > 200 > > >>> > cores spread between a couple of webapps on a single JVM on *AWS* > > >>> > > > >>> > All indexing [via a queue will go to master ] . One Slave Server > > will > > >>> > replicate all the core level indexes from the master , slave > > >>> Configurations > > >>> > are defined in the solr.xml at the webapp level with a different > > poll > > >>> > interval for each webapp. > > >>> > > > >>> > We are planning to LB the search requests by fronting the master > and > > >>> slave > > >>> > with an *AWS ELB *. The master configuration will not enable the > > slave > > >>> > properties as master is not replicating from any other machine. The > > >>> master > > >>> > and slave have similar hardware configurations [*High-Memory > > Quadruple > > >>> > Extra Large Instance] .*This is mainly for HA if the slave goes > down. > > >>> > * > > >>> > * > > >>> > Any issue with the above set up ,please advice. > > >>> > > > >>> > Regards, > > >>> > Sujatha > > >>> > > > >>> > > > >>> > > > >>> > > > >>> > * > > >>> > * > > >>> > > > >>> > > >> > > >> > > >
