Thanks all,

I am no doubt confusing things myself - I (rather stupidly) have 5 completely separate clouds, with separate ZK trees - a bad design decision on day one when I thought each config needed a separate ZK tree.

So it could all be simplified a bit, but that's my current view, which is probably sounding confused.

Cheers,
Rob


On 03/23/2016 04:03 PM, Tom Evans wrote:
On Wed, Mar 23, 2016 at 3:43 PM, Robert Brown <r...@intelcompute.com> wrote:
So I setup a new solr server to point to my existing ZK configs.

When going to the admin UI on this new server I can see the shards/replica's
of the existing collection, and can even query it, even tho this new server
has no cores on it itself.

Is this all expected behaviour?

Is there any performance gain with what I have at this precise stage?  The
extra server certainly makes it appear i could balance more load/requests,
but I guess the queries are just being forwarded on to the servers with the
actual data?

Am I correct in thinking I can now create a new collection on this host, and
begin to build up a new cluster?  and they won't interfere with each other
at all?

Also, that I'll be able to see both collections when using the admin UI
Cloud page on any of the servers in either collection?

I'm confused slightly:

SolrCloud is a (singular) cluster of servers, storing all of its state
and configuration underneath a single zookeeper path. The cluster
contains collections. Collections are tied to a particular config set
within the cluster. Collections are made up of 1 or more shards. Each
shard is a core, and there are 1 or more replicas of each core.

You can add more servers to the cluster, and then create a new
collection with the same config as an existing collection, but it is
still part of the same cluster. Of course, you could think of a set of
servers within a cluster as a "logical" cluster if it just serves
particular collection, but "cluster" to me would be all of the servers
within the same zookeeper tree, because that is where cluster state is
maintained.

Cheers

Tom

Reply via email to