Hi Parker, Lovely ASCII art. :)
Yes, I think you can simplify this by introducing shared storage (e.g., SAN) that hosts the index to which you active/primary master writes. When your primary master dies, you start your stand-by master that is configured to point to the same index. If there are any left-over index locks from the primary master, they can be removed (these is a property for that in solrconfig.xml) when Solr starts. Your Index VIP can then be pointed to the the new master. Slaves talk to the master via Index VIP, so they hardly notice this. And since the index is on the SAN, your slaves could actually point to that same index and avoid the whole replication process, thus removing one more moving piece, plus eliminating OS cache-unfriendly disk IO caused by index replication as a bonus feature. Repeaters are handy for DR (replication to the second DC) or when you have so many slaves that their (very frequent) replication requests and actual index replication are too much for a single master, but it doesn't sound like you need them here unless you really want to have your index or even mirror the whole cluster setup in a second DC. Otis ---- Sematext :: http://sematext.com/ :: Solr - Lucene - Nutch Lucene ecosystem search :: http://search-lucene.com/ ----- Original Message ---- > From: Parker Johnson <parker_john...@gap.com> > To: "solr-user@lucene.apache.org" <solr-user@lucene.apache.org> > Sent: Tue, April 12, 2011 6:33:08 PM > Subject: Vetting Our Architecture: 2 Repeaters and Slaves. > > > > I am hoping to get some feedback on the architecture I've been planning > for a medium to high volume site. This is my first time working > with Solr, so I want to be sure what I'm planning isn't totally weird, > unsupported, etc. > > We've got a a pair of F5 loadbalancers and 4 hosts. 2 of those hosts will > be repeaters (master+slave), and 2 of those hosts will be pure slaves. One > of the F5 vips, "Index-vip" will have members HOST1 and HOST2, but HOST2 > will be "downed" and not taking traffic from that vip. The second vip, > "Search-vip" will have 3 members: HOST2, HOST3, and HOST4. The > "Index-vip" is intended to be used to post and commit index changes. The > "Search-vip" is intended to be customer facing. > > Here is some ASCII art. The line with the "X"'s thru it denotes a > "downed" member of a vip, one that isn't taking any traffic. The "M:" > denotes the value in the solrconfig.xml that the host uses as the master. > > > Index-vip Search-vip > / \ / | \ > / X / | \ > / \ / | \ > / X / | \ > / \ / | \ > / X / | \ > / \ / | \ > HOST1 HOST2 HOST3 HOST4 > REPEATER REPEATER SLAVE SLAVE > M:Index-vip M:Index-vip M:Index-vip M:Index-vip > > > I've been working through a couple failure scenarios. Recovering from a > failure of HOST2, HOST3, or HOST4 is pretty straightforward. Loosing > HOST1 is my major concern. My plan for recovering from a failure of HOST1 > is as follows: Enable HOST2 as a member of the Index-vip, while disabling > member HOST1. HOST2 effectively becomes the Master. HOST2, 3, and 4 > continue fielding customer requests and pulling indexes from "Index-vip." > Since HOST2 is now in charge of crunching indexes and fielding customer > requests, I assume load will increase on that box. > > When we recover HOST1, we will simply make sure it has replicated against > "Index-vip" and then re-enable HOST1 as a member of the Index-vip and > disable HOST2. > > Hopefully this makes sense. If all goes correctly, I've managed to keep > all services up and running without loosing any index data. > > So, I have a few questions: > > 1. Has anyone else tried this dual repeater approach? > 2. Am I going to have any semaphore/blocking issues if a repeater is > pulling index data from itself? > 3. Is there a better way to do this? > > > Thanks, > Parker > > > > > > >
