On Sat, Jun 13, 2009 at 2:44 AM, Phil Hagelberg<p...@hagelb.org> wrote: > Shalin Shekhar Mangar <shalinman...@gmail.com> writes: > >> You are right. In Solr/Lucene, a commit exposes updates to searchers. So you >> need to call commit on the master for the slave to pick up the changes. >> Replicating changes from the master and then not exposing new documents to >> searchers does not make sense. However, there is a lot of work going on in >> Lucene to enable near real-time search (exposing documents to searchrs as >> soon as possible). Once those features are mature enough, Solr's replication >> will follow suit. > > I understand that; it's totally reasonable. > > What it doesn't explain is what happened in my case: the master added a > bunch of docs, committed, and then the slave replicated fine. Then the > slave lost all its data (due to me issuing an rm -rf of the data > directory, but let's say it happened due to a disk failure or something) > and tried to replicate again, but got zero docs. Once the master had > another commit issued, the slave could now replicate properly.
if you removed the files while the slave is running , then the slave will not know that you removed the files (assuming it is a *nix box) and it will serve the search requests. But if you restart the slave , it should have automatically picked up the current index. if it doesn't it is a bug > > I would expect in this case the slave should be able to replicate after > losing its data but before the second commit. I can see why the master > would not expose uncommitted documents, but I can't see why it would > refuse to allow _any_ of its index to be replicated from. > > I feel like I'm missing a piece of the picture here. > > -Phil > -- ----------------------------------------------------- Noble Paul | Principal Engineer| AOL | http://aol.com
