Thanks you very much for this info, that helps a lot!
On Wed, Mar 2, 2011 at 10:05 AM, Jayendra Patil
wrote:
> Hi Mike,
>
> There was an issue with the Snappuller wherein it fails to clean up
> the old index directories on the slave side.
> https://issues.apache.org/jira/browse/SOLR-2156
>
> Th
Hi Mike,
There was an issue with the Snappuller wherein it fails to clean up
the old index directories on the slave side.
https://issues.apache.org/jira/browse/SOLR-2156
The patch can be applied to fix the issue.
You can also delete the old index directories, except for the current
one which is m
Yes. But keep in mind that Solr may be actually using an index.
directory for its live search. See either the replication.properties file or
consult the replication page to see what index directory it uses.
If it uses an index. directory you can safely move it to index and
remove or modify repl
Is it ok if I just delete the old copies manually? or maybe run a
script that does it?
On Tue, Mar 1, 2011 at 7:47 PM, Markus Jelsma
wrote:
> Indeed, the slave should not have useless copies but it does, at least in
> 1.4.0, i haven't seen it in 3.x, but that was just a small test that did not
>
Right now I have the slave polling every 10 seconds, becuase we want
to make sure they stay in sync. I have users who will do post
directly from a web application. But I do notice it syncs very quick,
becuase usually the update is only one or two records at a time.
I am thinking maybe 10 seconds
Indeed, the slave should not have useless copies but it does, at least in
1.4.0, i haven't seen it in 3.x, but that was just a small test that did not
exactly meet my other production installs.
In 1.4.0 Solr does not remove old copies at startup and it does not cleanly
abort running replication
The slave should not keep multiple copies _permanently_, but might
temporarily after it's fetched the new files from master, but before
it's committed them and fully wamred the new index searchers in the
slave. Could that be what's going on, is your slave just still working
on committing and w
ok doing some more research I noticed, on the slave it has multiple
folders where it keeps them for example
index
index.20110204010900
index.20110204013355
index.20110218125400
and then there is an index.properties that shows which index it is using.
I am just curious why does it keep multiple c
No pending commits, what it looks like is there are almost two copies
of the index on the master, not sure how that happened.
On Tue, Mar 1, 2011 at 3:08 PM, Markus Jelsma
wrote:
> Are there pending commits on the master?
>
>> I was curious why would the size be dramatically different even thou
Are there pending commits on the master?
> I was curious why would the size be dramatically different even though
> the index versions are the same?
>
> One is 1.2 Gb, and on the slave it is 512 MB
>
> I would think they should both be the same size no?
>
> Thanks
I was curious why would the size be dramatically different even though
the index versions are the same?
One is 1.2 Gb, and on the slave it is 512 MB
I would think they should both be the same size no?
Thanks
11 matches
Mail list logo
