Thanks for the response. I am using Linux (RedHat).
It sounds like it may possibly be related to that bug.
But the thing is, the timestamped index directory is looking to me like
it's the _current_ one, with the non-timestamped one being an old out of
date one. So that does not seem to be quite the same thing reported in
that bug, although it may very well be related.
At this point, I'm just trying to figure out how to clean up. How to
verify which of those copies really is the current one, which is
currently being used by Solr -- and if it's the timestamped one, how to
restore things to the state where there's only one non-timestamped index
dir, ideally without downtime to Solr.
Anyone have any advice or ideas on those questions?
On 1/18/2012 1:23 PM, Artem Lokotosh wrote:
Which OS do you using?
Maybe related to this Solr bug
https://issues.apache.org/jira/browse/SOLR-1781
On Wed, Jan 18, 2012 at 6:32 PM, Jonathan Rochkind<rochk...@jhu.edu> wrote:
So Solr 1.4. I have a solr master/slave, where it actually doesn't poll for
replication, it only replicates irregularly when I issue a replicate command
to it.
After the last replication, the slave, in solr_home, has a data/index
directory as well as a data/index.20120113121302 directory.
The /admin/replication/index.jsp admin page reports:
Local Index
Index Version: 1326407139862, Generation: 183
Location: /opt/solr/solr_searcher/prod/data/index.20120113121302
So does this mean the index.XXXX file is actually the one currently being
used live, not the straight 'index'? Why?
I can't afford the disk space to leave both of these around indefinitely.
After replication completes and is committed, why would two index dirs be
left? And how can I restore this to one index dir, without downtime? If
it's really using the "index.XXXXX" directory, then I could just delete the
"index" directory, but that's a bad idea, because next time the server
starts it's going to be looking for "index", not "index.XXXX". And if it's
using the timestamped index file now, I can't delete THAT one now either.
If I was willing to restart the tomcat container, then I could delete one,
rename the other, etc. But I don't want downtime.
I really don't understand what's going on or how it got in this state. Any
ideas?
Jonathan
