I was thinking of the method described in SOLR-1305. Yes, near realtime replication will most likely be a different modality.
2009/7/22 Noble Paul നോബിള് नोब्ळ् <noble.p...@corp.aol.com>: > 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 >
