Phil Hagelberg writes:
> Noble Paul നോബിള് नोब्ळ् writes:
>
>> 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
Noble Paul നോബിള് नोब्ळ् writes:
> 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 cur
2009/6/13 Noble Paul നോബിള് नोब्ळ् :
> 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.
Hmmm, but for pulling a snapshot, it looks like we do verify that the
file s
On Sat, Jun 13, 2009 at 2:44 AM, Phil Hagelberg wrote:
> Shalin Shekhar Mangar 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 ex
Shalin Shekhar Mangar 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. Howe
On Sat, Jun 13, 2009 at 1:25 AM, Phil Hagelberg wrote:
>
> OK, so I inserted some more documents into the master, and now
> replication works. I get the feeling it may be due to this line in the
> master's solrconfig.xml:
>
> commit
>
> Now this is confusing since it seems that the timing of rep
Phil Hagelberg writes:
> My only guess as to what's going wrong here is that deleting the
> coreN/data directory is not a good way to "reset" a core back to its
> initial condition. Maybe there's a bit of state somewhere that's making
> the slave think that it's already up-to-date with this maste
I'm trying out the replication features on 1.4 (trunk) with multiple
indices using a setup based on the example multicore config.
The first time I tried it, (replicating through the admin web
interface), it worked fine. I was a little surprised that telling one
core to replicate caused both to re
