You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-commits@lucene.apache.org by Apache Wiki <wi...@apache.org> on 2011/09/07 18:52:45 UTC

[Solr Wiki] Trivial Update of "SolrCloud" by Pulkit Singhal

Dear Wiki user,

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

The "SolrCloud" page has been changed by Pulkit Singhal:
http://wiki.apache.org/solr/SolrCloud?action=diff&rev1=37&rev2=38

   * {{{-DzkRun}}} causes an embedded zookeeper server to be run as part of this Solr server.
   * {{{-Dbootstrap_confdir=./solr/conf}}} Since we don't yet have a config in zookeeper, this parameter causes the local configuration directory {{{./solr/conf}}} to be uploaded as the "myconf" config.  The name "myconf" is taken from the "collection.configName" param below.
   * {{{-Dcollection.configName=myconf}}} sets the config to use for the new collection.
- 
  
  Browse to http://localhost:8983/solr/collection1/admin/zookeeper.jsp to see the state of the cluster (the zookeeper distributed filesystem).
  
@@ -99, +98 @@

  
  http://localhost:7500/solr/collection1/select?distrib=true&q=*:*
  
- Send this query multiple times and observe the logs from the solr servers.  From your web browser, you may need to hold down CTRL while clicking on the browser refresh button to bypass the HTTP caching in your browser.  You should be able to observe Solr load balancing the requests across shard replicas, using different servers to satisfy each request.  There will be a log statement for the top-level request in the server the browser sends the request to, and then a log statement for each sub-request that are merged to produce the complete response.
+ Send this query multiple times and observe the logs from the solr servers.  From your web browser, you may need to hold down CTRL while clicking on the browser refresh button to bypass the HTTP caching in your browser.  You should be able to observe Solr load balancing the requests (done via LBHttpSolrServer ?) across shard replicas, using different servers to satisfy each request.  There will be a log statement for the top-level request in the server the browser sends the request to, and then a log statement for each sub-request that are merged to produce the complete response.
  
  To demonstrate fail over for high availability, go ahead and kill any one of the Solr servers (just press CTRL-C in the window running the server) and and send another query request to any of the remaining servers that are up.
  
@@ -142, +141 @@

  
  When Solr runs an embedded zookeeper server, it defaults to using the solr port plus 1000 for the zookeeper client port.  In addition, it defaults to adding one to the client port for the zookeeper server port, and two for the zookeeper leader election port.  So in the first example with Solr running at 8983, the embedded zookeeper server used port 9983 for the client port and 9984,9985 for the server ports.
  
- 
  == Creating cores via CoreAdmin ==
  New Solr cores may also be created and associated with a collection via CoreAdmin.
  
  Additional cloud related parameters for the CREATE action:
+ 
   * '''collection''' - the name of the collection this core belongs to.  Default is the name of the core.
   * '''shard''' - the shard id this core represents
   * '''collection.<param>=<value>''' - causes a property of <param>=<value> to be set if a new collection is being created.
-   *  Use  collection.configName=<configname> to point to the config for a new collection. 
+   * Use  collection.configName=<configname> to point to the config for a new collection.
  
  Example:
+ 
  {{{
  curl 'http://localhost:8983/solr/admin/cores?action=CREATE&name=mycore&collection=collection1&shard=shard2'
  }}}
- 
- 
  == Distributed Requests ==
  Explicitly specify the addresses of shards you want to query: