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. 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
