Interestingly that worked. I deleted the slave index and restarted.
After the first replication I shut down the server, deleted the lock
file and started it again. It seems to be behaving itself now even
though a lock file seems to be recreated. Thanks a lot for the help.
This still seems like a bu
I see the file
-rw-rw-r-- 1 feeddo feeddo0 Dec 15 01:19
lucene-cdaa80c0fefe1a7dfc7aab89298c614c-write.lock
was created on Dec. 15. At the end of the replication, as far as I
remember, the SnapPuller tries to open the writer to ensure the old
files are deleted, and in
your case it cannot obtai
The file system checked out, I also tried creating a slave on a
different machine and could reproduce the issue. I logged SOLR-2329.
On Sat, Dec 18, 2010 at 8:01 PM, Lance Norskog wrote:
> This could be a quirk of the native locking feature. What's the file
> system? Can you fsck it?
>
> If this
unsubscribe
On Mon, Jan 3, 2011 at 5:22 AM, Markus Jelsma wrote:
> I'm seeing this issue as well on 1.4.1 where all slaves are using simple as
> the locking mechanism. For some unknown reason slaves either don't remove
> old
> index.DATE directories or old index files in the index directory. Only
I'm seeing this issue as well on 1.4.1 where all slaves are using simple as
the locking mechanism. For some unknown reason slaves either don't remove old
index.DATE directories or old index files in the index directory. Only the
second slave has the correct index size.
master
4.8Gindex
4.8G
info.
--
View this message in context:
http://lucene.472066.n3.nabble.com/old-index-files-not-deleted-on-slave-tp2113493p2167789.html
Sent from the Solr - User mailing list archive at Nabble.com.
You should use Locktype 'simple' instead of 'single'. I've never
heard of a .nfs000* file.
On Tue, Dec 28, 2010 at 8:42 PM, sakunthalakishan
wrote:
>
> We are using Locktype "single".
> --
> View this message in context:
> http://lucene.472066.
We are using Locktype "single".
--
View this message in context:
http://lucene.472066.n3.nabble.com/old-index-files-not-deleted-on-slave-tp2113493p2161030.html
Sent from the Solr - User mailing list archive at Nabble.com.
deleted. And these .nfs files
are still being used by SOLR in jboss.
This setup is giving issue only in linux. Is this known bug on linux?
--
View this message in context:
http://lucene.472066.n3.nabble.com/old-index-files-not-deleted-on-slave-tp2113493p2160924.html
Sent from the Solr
This could be a quirk of the native locking feature. What's the file
system? Can you fsck it?
If this error keeps happening, please file this. It should not happen.
Add the text above and also your solrconfigs if you can.
One thing you could try is to change from the native locking policy to
the
I have set up index replication (triggered on optimize). The problem I
am having is the old index files are not being deleted on the slave.
After each replication, I can see the old files still hanging around
as well as the files that have just been pulled. This causes the data
directory size to in
11 matches
Mail list logo