A Collection is simply the "SolrCloud" way of thinking about a logical
index that incorporates shards, replication factors changing topology
of where the replicas live and the like. In your case it's synonymous
with your core (master and slaves). Since there's no master or slave
role in SolrCloud,
Thanks so much for your reply. That's clarified a few things for me.
Erick Erickson wrote:
> Where SolrCloud becomes compelling is when you _do_ need to have
> shard, and deal with HA/DR.
I'm not using shards since the indicies are small enough, however I use
master/slave with 6 nodes for two
Thanks so much for your reply. That's clarified a few things for me.
Erick Erickson wrote:
> Where SolrCloud becomes compelling is when you _do_ need to have
> shard, and deal with HA/DR.
I'm not using shards since the indicies are small enough, however I use
master/slave with 6 nodes for two
bq: Zookeeper seems a step backward.
For stand-alone Solr, I tend to agree it's a bit awkward. But as Shawn
says, there's no _need_ to run Zookeeper with a more recent Solr.
Running Solr without Zookeeper is perfectly possible, we call that
"stand alone". And, if you have no need for sharding
On 22/07/2016 5:22pm, Aristedes Maniatis wrote:
> But then what? In the production cluster it seems I then need to
>
> 1. Grab the latest configuration bundle for each core and unpack them
> 2. Launch Java
> 3. Execute the Solr jars (from the production server since it must be the
> right
On 7/22/2016 1:22 AM, Aristedes Maniatis wrote:
> I'm not new to Solr, but I'm upgrading from Solr 4 to 5 and needing to
> use the new Zookeeper configuration requirement. It is adding a lot of
> extra complexity to our deployment and I want to check that we are
> doing it right.
Zookeeper is