This replication does not work well. temp directory  and /data/index are on 
different device/disks



I see the following message



[2010-03-02 01:22:07] [pool-3-thread-1] ERROR(ReplicationHandler.java:266) - 
SnapPull failed 



And Yet I applied the patch SOLR-1736 



I ll uni test patch SOLR-1736  and see what tmpIdxDir gets picked up...



What would be cool is the ability to set up solr temp file via config file so 
that it can live in the same partition than the data directory



Thank you

--- On Fri, 2/26/10, Shalin Shekhar Mangar <shalinman...@gmail.com> wrote:

From: Shalin Shekhar Mangar <shalinman...@gmail.com>
Subject: Re: replication issue
To: solr-user@lucene.apache.org
Date: Friday, February 26, 2010, 2:06 PM

On Sat, Feb 27, 2010 at 12:13 AM, Matthieu Labour <matthieu_lab...@yahoo.com
> wrote:

> Hi
>
> I am still having issues with the replication and wonder if things are
> working properly
>
> So I have 1 master and 1 slave
>
> On the slave, I deleted the data/index directory and
> data/replication.properties file and restarted solr.
>
> When slave is pulling data from master, I can see that the size of data
> directory is growing
>
> r...@slr8:/raid/data# du -sh
> 3.7M    .
> r...@slr8:/raid/data# du -sh
> 4.7M    .
>
> and I can see that data/replication.properties  file got created and also a
> directory data/index.20100226063400
>
> soon after index.20100226063400 disapears and the size of data/index is
> back to 12K
>
> r...@slr8:/raid/data/index# du -sh
> 12K    .
>
> And when I look for the number of documents via the admin interface, I
> still see 0 documents so I feel something is wrong
>
> One more thing, I have a symlink for /solr/data ---> /raid/data
>

The ReplicationHandler moves files out of the temp directory into the index
directory. Java's File#renameTo can fail if the source and target
directories are on different partitions/disks. Is that the case here? I
believe SOLR-1736 fixes this issue in trunk but that was implemented after
the 1.4 release.

-- 
Regards,
Shalin Shekhar Mangar.



      

Reply via email to