Mailing-List: contact solr-commits-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: solr-dev@lucene.apache.org
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: Apache Wiki <wikidiffs@apache.org>
To: Apache Wiki <wikidiffs@apache.org>
Date: Mon, 05 Sep 2011 21:38:24 -0000
Message-ID: <20110905213824.84712.897@eos.apache.org>
Subject: 
 =?utf-8?q?=5BSolr_Wiki=5D_Update_of_=22NewSolrCloudDesign=22_by_YonikSeel?=
 =?utf-8?q?ey?=
Auto-Submitted: auto-generated

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Solr Wiki" for chan=
ge notification.

The "NewSolrCloudDesign" page has been changed by YonikSeeley:
http://wiki.apache.org/solr/NewSolrCloudDesign?action=3Ddiff&rev1=3D10&rev2=
=3D11

Comment:
add single node startup usecase

  It may be simpler to have a coordinator node (we avoid the term master si=
nce that is associated with traditional index replication) that is establis=
hed via leader election.
  Following a pattern of treating the zookeeper state as the "truth" and ha=
ving nodes react to changes in that state allow for more future flexibility=
 (such as allowing an external management tool directly change the zookeepe=
r state to control the cluster).  Having a coordinator (as opposed to grabb=
ing a lock every time) can be more scalable too.  A hybrid model where a cl=
uster lock is used only in certain circumstances can also make sense.
  =

+ =3D=3D Single Node Simplest Use Case =3D=3D
+ We should be able to easily start up a single node and start indexing doc=
uments.  At a later point in time, we should be able to start up a second n=
ode and have it join the cluster.
+ =

+  1. start up a single node, upload it's configuration (the first time) to=
 zookeeper, and create+assign the node to shard1.
+   * in the absence of other information when the config is created, a sin=
gle shard system is assumed
+  1. index some documents
+  1. start up another node and pass it a parameter that says "if you are n=
ot already assigned, assign yourself to any shard that has the lowest numbe=
r of replicas and start recovery process"
+   * avoid replicating a shard on the same host if possible
+   * after this point, one should be able to kill the node and start it up=
 again and have it resume the same role (since it should see itself in zook=
eeper)
+=20