Would love to help. Bill Bell Sent from mobile
On Feb 23, 2011, at 2:42 AM, Jan Høydahl <jan....@cominvent.com> wrote: > Hi, > > This is what we're aiming for SolrCloud and ZooKeeper to handle for us. > It does not currently do that, but the vision is that ZK will keep track of > the state of each node, and do master election and everything. Contributions > welcome :) > > http://wiki.apache.org/solr/SolrCloud > > -- > Jan Høydahl, search solution architect > Cominvent AS - www.cominvent.com > > On 23. feb. 2011, at 10.02, <krist...@online.no> <krist...@online.no> wrote: > >> Hi, >> >> I am working on a setup where we will need fault tolerant indexing. This >> seems not to be supported by Solr per default, and I wonder what the options >> are. >> >> My plan is to: >> * Use 2 separate, self-contained Solr nodes (no master-slave config in Solr) >> * Use a hot standby failover setup in front of the nodes >> * Put the index on a file system (Oracle DBFS) shared between the nodes >> * Let a single node perform both indexing and searching at any given time >> >> The idea is that if the active node goes down, the standby node will take >> over and receive both search and indexing traffic. (I will need to ensure >> that the failover soluition ensures that only one node can read and write to >> the index at any given time.) >> >> This way, the active node, when it recovers, will have access to all index >> updates that have taken place while it was down. (I assume that Solr on the >> active node will get a new Reader when it starts - so any updates since last >> commit from that node will be available.) >> >> A "classic" Solr master-slave setup with local indexes on the nodes will >> AFAIK in this case not be sufficient since the master (when it starts again >> after downtime) will not be able to replicate from the slave and thus any >> index updates sent to the slave (while the master was down) will be lost. >> >> This could be solved if the roles of the master and the slave were switched >> when the master goes down. AFAIK this is not easily supported. >> >> Any suggestions are very welcome! >> >> >> Kristoffer >