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
