lucene-solr-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <>
Subject [Solr Wiki] Update of "NewSolrCloudDesign" by YonikSeeley
Date Mon, 05 Sep 2011 21:38:24 GMT
Dear Wiki user,

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

The "NewSolrCloudDesign" page has been changed by YonikSeeley:

add single node startup usecase

  It may be simpler to have a coordinator node (we avoid the term master since that is associated
with traditional index replication) that is established via leader election.
  Following a pattern of treating the zookeeper state as the "truth" and having nodes react
to changes in that state allow for more future flexibility (such as allowing an external management
tool directly change the zookeeper state to control the cluster).  Having a coordinator (as
opposed to grabbing a lock every time) can be more scalable too.  A hybrid model where a cluster
lock is used only in certain circumstances can also make sense.
+ == Single Node Simplest Use Case ==
+ We should be able to easily start up a single node and start indexing documents.  At a later
point in time, we should be able to start up a second node 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 single shard system
is assumed
+  1. index some documents
+  1. start up another node and pass it a parameter that says "if you are not already assigned,
assign yourself to any shard that has the lowest number 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 zookeeper)

View raw message