lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erick Erickson <>
Subject Re: Problem in Issuing a Command to Upload Configuration
Date Tue, 03 May 2016 14:06:21 GMT
If Solr is killed un-gracefully, " it can leave the lock files
in the index directory and when Solr comes back up
it thinks some other Solr process is writing the files
and refuses to allow _this_ Solr process to write to
those files

Probably this:
bq:  machines faced a forced
restart to install Windows Updates

shut the Solr instances down un-gracefully. So next time
Windows "helpfully" wants to kill all your processes,
don't let it until you've stopped Solr gracefully via the
bin\solr script.

BTW, I've seen some situations where the bin/solr script
will forcefully kill the Solr instance.

And to cure the situation, remove the write.lock file from the
index   directory (when Solr is stopped) and then start


On Mon, May 2, 2016 at 2:36 AM, Salman Ansari <> wrote:
> Well, that just happened! Solr and Zookeeper machines faced a forced
> restart to install Windows Updates. This caused Zookeeper ensemble and Solr
> instances to go down. When the machines came back up again. I tried the
> following
> 1) Started Zookeeper on all machines using the following command
> zkServer.cmd (on all three machines)
> 2) Started Solr on two of those machines using
> solr.cmd start -c -p 8983 -h [server1_name] -z
> "[server1_ip]:2181,[server2_name]:2181,[server3_name]:2181"
> solr.cmd start -c -p 8983 -h [server2_name] -z
> "[server2_ip]:2181,[server1_name]:2181,[server3_name]:2181"
> solr.cmd start -c -p 7574 -h [server1_name] -z
> "[server1_ip]:2181,[server2_name]:2181,[server3_name]:2181"
> solr.cmd start -c -p 7574 -h [server2_name] -z
> "[server2_ip]:2181,[server1_name]:2181,[server3_name]:2181"
> After several trials, it did start the solr on both machines but *non of
> the previous collections came back normally.* When I look at the admin
> page, it shows errors as follows
> *[Collection_name]_shard2_replica2:*
> org.apache.solr.common.SolrException:org.apache.solr.common.SolrException:
> Index locked for write for core '[Collection_name]_shard2_replica2'. Solr
> now longer supports forceful unlocking via 'unlockOnStartup'. Please verify
> locks manually!
> So probably I am doing something wrong or the simple scenario is not
> straight forward to recover from.
> Your comment/feedback is appreciated.
> Regards,
> Salman
> On Thu, Apr 7, 2016 at 3:56 PM, Shawn Heisey <> wrote:
>> On 4/7/2016 5:40 AM, Salman Ansari wrote:
>> > Any comments regarding the issue I mentioned above "the proper procedure
>> of
>> > bringing old collections up after a restart of zookeeper ensemble and
>> Solr
>> > instances"?
>> What precisely do you mean by "old collections"?  The simplest
>> interpretation of that is that you are trying to restart your servers
>> and have everything you already had in the cloud work properly.  An
>> alternate interpretation, which might be just as valid, is that you have
>> some collections on some old servers that you want to incorporate into a
>> new cloud.
>> If it's the simple scenario: shut down solr, shut down zookeeper, start
>> zookeeper, start solr.  If it's the other scenario, that is not quite so
>> simple.
>> Thanks,
>> Shawn

View raw message