Mailing-List: contact solr-user-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: solr-user@lucene.apache.org
MIME-Version: 1.0
In-Reply-To: <529991890.6411276.1499889491131@mail.yahoo.com>
References: <529991890.6411276.1499889491131.ref@mail.yahoo.com> <529991890.6411276.1499889491131@mail.yahoo.com>
From: Erick Erickson <erickerickson@gmail.com>
Date: Wed, 12 Jul 2017 15:22:20 -0700
Message-ID: <CAN4YXvdPyd9FD0cjmfpU7yKvCaYx--7mMQu2Jiq8BR-aRk5cdQ@mail.gmail.com>
Subject: Re: Cluster without sharding
To: solr-user <solr-user@lucene.apache.org>,
	Mikhail Ibraheem <mikhail.ibraheem@yahoo.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
archived-at: Wed, 12 Jul 2017 22:23:06 -0000

1> I would not do this. First there's the lock issues you mentioned.
But let's say replica1 is your indexer and replicas2 and 3 point to
the same index. When replica1 commits, now do replicas 2 and 3 know to
open a new searcher?

<2> and <3> just seem like variants of coupling Solr instances to
collections, which I'd advise against.

I'd just have a single collection with 1 shard and that shard has as
many replicas as you need, spread across as many Solr instances as you
want. CloudSolrClient takes care of load balancing with an internal
software load balancer and is aware of ZooKeeper so it can "do the
right thing". Updates get sent to all replicas and indexed locally. Do
not try to share indexes

You get all the HA/DR of SolrCloud.

If that doesn't work, _then_ worry about more complex schemes.

Best,
Erick

On Wed, Jul 12, 2017 at 12:58 PM, Mikhail Ibraheem
<mikhail.ibraheem@yahoo.com.invalid> wrote:
> Hi,We are using some features like collapse and joins that force us not t=
o use sharding for now. Still i am checking for possibilities for load bala=
ncing and high availability.1- I think about using many solr instances run =
against the same shard file system. This way all instances will work with t=
he same data. I know there may be issues with synchronization and open seac=
hers. But my main concern with this, will we have some lock issues like dea=
dlock between instances?
> 2- Having some collections owned by each instance. For example if I have =
9 collections and 3 solr instances, I will divide the collections so that 3=
 collections owned by each instance.3- Can I influence the order of the sol=
rCloud Client? I mean if I have 3 instances ins1, ins2 and ins3. Am I able =
to ask the solrCloudClient to try ins1 first, then ins2 and finally try ins=
3?
> Any more suggestions is more  than appreciated.
> ThanksMikhail