There is an issue already created for realtime replication https://issues.apache.org/jira/browse/SOLR-982
In general push based replication is more error prone because the master has to be aware of the state of each slave . it is difficault because a slave may go down at any time and may come up later or new slaves get added randomly. In a pull based replication the master is agnostic of the slaves and a slave can easily know his current state and take appropriate action. We can take a middle path. The slaves can register with the master for notifications for availability of new snapshots. This can be as good as a push based replication without the complexities associated with it. I have raised as issue already https://issues.apache.org/jira/browse/SOLR-1305 On Thu, Jul 23, 2009 at 2:58 AM, Jason Rutherglen<jason.rutherg...@gmail.com> wrote: > It would be useful to push snapshots as they are created from > the master to the slaves. I prefer this approach to constant > polling by slaves. Partially because the timing could be off on > the slave servers, the data is replicated, and the user sees > different snapshots? > > Something like a virtual 2 phase commit, where phase 1 is > replicate the new snapshots and load the searcher, phase two is > all slaves synchronously expose the new searcher. I'm also > wondering how we'll handle synchronous slaves with near realtime > search. > -- ----------------------------------------------------- Noble Paul | Principal Engineer| AOL | http://aol.com
