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
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
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
Moreover, I have created those new collections as a work around as my past
collections were not coming up after a complete restart for machines
hosting zookeepers and Solr. I would be interested to know what is the
proper procedure of bringing old collections up after a restart of
zookeeper
Thanks Reth for your response. It did work.
Regards,
Salman
On Mon, Mar 28, 2016 at 8:01 PM, Reth RM wrote:
> I think it should be "zkcli.bat" (all in lower case) that is shipped with
> solr not zkCli.cmd(that is shipped with zookeeper)
>
>
I think it should be "zkcli.bat" (all in lower case) that is shipped with
solr not zkCli.cmd(that is shipped with zookeeper)
solr_home/server/scripts/cloud-scripts/zkcli.bat -zkhost 127.0.0.1:9983 \
-cmd upconfig -confname my_new_config -confdir
server/solr/configsets/basic_configs/conf
On
Hi,
I am facing issue uploading configuration to Zookeeper ensemble. I am
running this on Windows as
*Command*
**
zkCli.cmd -cmd upconfig -zkhost
"[localserver]:2181,[second_server]:2181,[third_server]:2181" -confname
[config_name] -confdir "[config_dir]"
and I got the following result