lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Collins <>
Subject Re: Switching zk node cause load conf error
Date Fri, 20 May 2016 17:02:18 GMT
Zk holds more than just the Solr config, it holds a copy of the
clusterstate, which includes all the sharding, hash ranges, etc as well.
You will need to re-create that data on your new ZK instance, i.e.
re-create the collection to populate that.

You do realize that running a single ZK instance is relatively dangerous
though (for production at least)?  If that ZK dies or is shutdown, you have
no failover, and your cloud will become read-only (since Solr won't be able
to find the leader for any shard)

On 20 May 2016 at 17:50, Scott Chu <> wrote:

> Even worse when I startup Solrclouds nodes and point back the original
> co-op zk nodes. It shows can't load conf for shard 2. It seems pointing to
> standalone zk node previously already hurt some config data so that the
> Solrcloud nodes can no long talk to original co-op zk nodes perfectly. Is
> it possible to repair the config data?
> Scott Chu,
> 2016/5/21 (週六)
> ----- Original Message -----
> From: scott.chu
> To: solr-user
> CC:
> Date: 2016/5/21 (週六) 00:44
> Subject: Switching zk node cause load conf error
> I intially start up 3 zk nodes and upload config 'cugna'. Then I start 2
> Solrcloud nodes, create collection with 2 shards, add a lot of docs ok.
> Later I find 3 zk nodes occupy too many CPU and memory, so I start a
> standalone zk node and use Solr's zkcli to upload same config 'cugna'.
> This time I start same 2 Solrcloud nodes but point to this standalone zk
> node. They seem to start ok.
> However, when I open localhost:8983, it shows can't load config for shard1
> and shard2.
> Does this mean I can't switch other zk nodes once after I create index?
> The same config on co-op and standalone seem to have difference?
> Scott Chu,
> 2016/5/21 (週六)
> -----
> 未在此訊息中找到病毒。
> 已透過 AVG 檢查 -
> 版本: 2015.0.6201 / 病毒庫: 4568/12265 - 發佈日期: 05/20/16

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message