lucene-solr-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Solr Wiki] Trivial Update of "SolrCloud" by Pulkit Singhal
Date Wed, 07 Sep 2011 16:52:45 GMT
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:
  

Mime
View raw message