How do you shut down your Solrs? Any kind of un-graceful stopping (kill -9 is a favorite) may leave the lock file around.
It can't be coming from nowhere, so my guess is that it's present in the source or destination before you do your copy... Best, Erick On Mon, May 9, 2016 at 10:30 AM, A Laxmi <a.lakshmi...@gmail.com> wrote: > yes, I always shutdown both source and destination Solr before copying the > index over from one to another. Somehow the write.lock only happens when > Solr restarts from service script. If loads just fine when started manually. > > On Mon, May 9, 2016 at 1:20 PM, Abdel Belkasri <belka...@gmail.com> wrote: > >> Did you copy the core while solr is running? if yes, first shuown source >> and destination solr, copy intex to the other solr, then restat solr nodes. >> Lock files get written to the core while solr is running and doing indexing >> or searching, etc. >> >> On Mon, May 9, 2016 at 12:38 PM, A Laxmi <a.lakshmi...@gmail.com> wrote: >> >> > Hi, >> > >> > I have installed Solr 5.3.1 using the Service Installation Script. I was >> > able to successfully start and stop Solr using service solr start/stop >> > commands and Solr loads up just fine. >> > >> > However, when I stop Solr service and copy an index of a core from one >> > server to another with same exact version of Solr and its corresponding >> > conf and restart the service, it complains about write.lock file when >> none >> > exists under the path that it specifies in the log. >> > >> > To validate whether the issue is with the data that is being copied or >> the >> > service script itself, I copied the collection directory with new index >> > into example-DIH directory and restarted Solr manually bin/solr start -e >> > dih -m 2g, it worked without any error. So, atleast this validates that >> > collection data is just fine and service script is creating a lock >> > everytime a new index is copied from another server though it has the >> same >> > exact Solr version. >> > >> > Did anyone experience the same? Any thoughts if this is a bug? >> > >> > Thanks! >> > AL >> > >> >> >> >> -- >> Abdel K. Belkasri, PhD >>
