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] Update of "SolrCloud" by DavidButtler
Date Thu, 16 Aug 2012 18:19:57 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 DavidButtler:
http://wiki.apache.org/solr/SolrCloud?action=diff&rev1=66&rev2=67

Comment:
added a sentence describing how to get graceful degraded behavior if some shards are not responding

  == Getting Started ==
  Download Solr 4-Beta or greater: http://lucene.apache.org/solr/downloads.html
  
- If you haven't yet, go through the simple [[http://lucene.apache.org/solr/tutorial.html|Solr
Tutorial]] to familiarize yourself with Solr. Note: delete all documents from your tutorial
before using cloud features, or counts may be off.
+ If you haven't yet, go through the simple [[http://lucene.apache.org/solr/tutorial.html|Solr
Tutorial]] to familiarize yourself with Solr. Note: reset all configuration and remove documents
from the tutorial before going through the cloud features. Copying the example directories
with pre-existing Solr indexes will cause document counts to be off.
  
  Solr embeds and uses Zookeeper as a repository for cluster configuration and coordination
- think of it as a distributed filesystem that contains information about all of the Solr
servers.
  
@@ -105, +105 @@

  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.
+ 
+ To demonstrate graceful degraded behavior, kill all but one of the Solr servers (just press
CTRL-C in the window running the server) and and send another query request to the remaining
server. By default this will return 0 documents.  To return just the documents that are available
in the shards that are still alive, add the following query parameter: shards.tolerant=true
  
  SolrCloud uses leaders and an overseer as an implementation detail. This means that some
shards/replicas will play special roles. You don't need to worry if the instance you kill
is a leader or the cluster overseer - if you happen to kill one of these, automatic fail over
will choose new leaders or a new overseer transparently to the user and they will seamlessly
takeover their respective jobs. Any Solr instance can be promoted to one of these roles.
  

Mime
View raw message