Hi Peter, Not sure I have the answer for you, but are you looking to avoid using ZK for some reason? Or are you OK with ZK per se, but just don't want any leader re-election and any other dynamic/cloudy behaviour?
Could you not simply treat 1 node as the "master" to which you send all your updates and let SolrCloud distribute that to the rest of the cluster? Is your main/only worry around what happens if this 1 node that you designated as the master goes down? What would you like to happen? You'd like indexing to start failing, while the search functionality remains up? Otis -- Search Analytics - http://sematext.com/search-analytics/index.html Performance Monitoring - http://sematext.com/spm/index.html On Sun, Nov 11, 2012 at 7:42 PM, Peter Wolanin <peter.wola...@acquia.com>wrote: > Looking at how we could upgrade some of our infrastructure to Solr 4.0 > - I would really like to take advantage of distributed updates to get > NRT, but we want to keep our fixed master and slave server roles since > we use different hardware appropriate to the different roles. > > Looking at the solr 4.0 distributed update code, it seems really > hard-coded and bound to zookeeper. Is there a way to have a solr > master distribute updates without using ZK, or a way to mock the ZK > interface to provide a fixed cluster topography that will work when > sending updates just to the master? > > To be clear, if the master goes doen I don't want a slave promoted, > nor do I want most of the other SolrCloud features - we have already > built out a system for managing groups of servers. > > Thanks, > > Peter >
