Hi YoniK. I'll check if I comment about it at this level and if it's OK I'll bring other details. Sorry if I can't do it right now, but I don't want to brake my company's policies.
Well I believe I can live with some staleness at certain moments, but it's not good as users are supposed to need it 24x7. So the common practice is to make one of the slaves as the new master and switch things over to it and after the outage put them in sync again and do the proper switch back? OK, I'll follow this, but I'm still concerned about the amount of manual steps to be done... It would be really great having a more automated way of handling this situations... Maybe I can think a bit more about it and come with a suggestion to be discussed here about how to make this failover transparent or close to it... I'm setting up a backup task to keep a copy of my master index, just to avoid having to re-build my index from scratch. And other important issue is how frequently have you seen indexes getting corrupted? If I try to run a commit or optimize on a Solr master instance and it's index got corrupted will it run the command? And more importantly, will it run the postOptimize/postCommit scripts generating snapshots and then possibly propagating the bad index? Thanks again, Daniel On 8/10/07 16:12, "Yonik Seeley" <[EMAIL PROTECTED]> wrote: > On 10/8/07, Daniel Alheiros <[EMAIL PROTECTED]> wrote: >> I'm about to deploy SOLR in a production environment > > Cool, can you share exactly what it will be used for? > >> and so far I'm a bit >> concerned about availability. >> >> I have a system that is responsible for fetching data from a database and >> then pushing it to SOLR using its XML/HTTP interface. >> >> So I'm going to deploy N instances of my application so it's going to be >> redundant enough. >> >> And I'm deploying SOLR in a Master / Slaves structure, so I'm using the >> slaves nodes as a way to keep my index replicated and to be able to use them >> to serve my queries. But my problem lies on the indexing side of things. Is >> there a good alternative like a Master/Master structure that I could use so >> if my current master dies I can automatically switch to my secondary master >> keeping my index integrity? > > In all the setups I've dealt with, master redundancy wasn't an issue. > If something bad happens to corrupt the index, shut off replication to > the slaves and do a complete rebuild on the master. If the master > hardware dies, reconfigure one of the slaves to be the new master. > These are manual steps and assumes that it's not the end of the world > if your search is "stale" for a couple of hours. A schema change that > required reindexing would also cause this window of staleness. > > If your index build takes a long time, you could set up a secondary > master to pull from the primary (just like another slave). But > there's no support for automatically switching over slaves, and the > secondary wouldn't have stuff between the last commit and the primary > crash... so something would need to update it... (query for latest doc > and start from there). > > You could also have two search tiers... another copy of the master and > multiple slaves. If one was down, being upgraded, or being rebuilt, > you could direct search traffic to the other set of servers. > > -Yonik http://www.bbc.co.uk/ This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this.
