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 "SolrReplication" by HossMan
Date Sat, 15 Aug 2009 07:19:59 GMT
Dear Wiki user,

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

The following page has been changed by HossMan:
http://wiki.apache.org/solr/SolrReplication

The comment on the change is:
link to older script replication wiki, and secition header normalization

------------------------------------------------------------------------------
+ 
  <!> ["Solr1.4"]
  
- [[TableOfContents]]
+ This document describes the Java implementation of index replication that works over HTTP
and was introduced in ["Solr1.4"].  For information on the ssh/rsync based replication available
since ["Solr1.1"] please consult CollectionDistribution.
+ 
+ <!> ["Solr1.4"]
  
  = Features =
   * Replication without requiring external scripts
@@ -18, +21 @@

  
  The new Java-based replication feature is implemented as a !RequestHandler. Configuring
replication is therefore similar to any normal !RequestHandler.
  
- === Master ===
+ == Master ==
  {{{
  <requestHandler name="/replication" class="solr.ReplicationHandler" >
      <lst name="master">
@@ -38, +41 @@

   * If your commits are very frequent and network is particularly slow, you can tweak an
extra attribute {{{<str name="commitReserveDuration">00:00:10</str>}}}. This is
roughly the time taken to download 5MB from master to slave. Default is 10 secs.
   * If you are using '''startup''' option for ''replicateAfter'', it is necessary to have
a '''commit'''/'''optimize''' entry also, if you want to trigger replication on future commits/optimizes.
If only the '''startup''' option is given, replication will not be triggered on subsequent
commits/optimizes after it is done for the first time at the start.
  
- ==== Replicating solrconfig.xml ====
+ === Replicating solrconfig.xml ===
  In the configuration file on the master server, include a line like the following:
  {{{
  <str name="confFiles">solrconfig_slave.xml:solrconfig.xml,x.xml,y.xml</str>
@@ -47, +50 @@

  
  On the master server, the file name of the slave configuration file can be anything, as
long as the name is correctly identified in the "confFiles" string; then it will be saved
as whatever file name appears after the colon ':'.
   
- === Slave ===
+ == Slave ==
  {{{
  <requestHandler name="/replication" class="solr.ReplicationHandler" >
      <lst name="slave">
@@ -82, +85 @@

  '''Note:''' 
  If you are not using cores, then you simply omit the "corename" parameter above in the masterUrl.
To ensure that the url is correct, just hit the url with a browser. You must get a status
OK response.
  
- === Setting up a Repeater ===
+ == Setting up a Repeater ==
  A master may be able to serve only so many slaves without affecting performance. Some organizations
have deployed slave servers across multiple data centers. If each slave downloads the index
from a remote data center, the resulting download may consume too much network bandwidth.
To avoid performance degradation in cases like this, you can configure one or more slaves
as repeaters.  A repeater is simply a node that acts as both a master and a slave.
   * To configure a server as a repeater, both the master and slave configuration lists need
to be present inside the !ReplicationHandler requestHandler in the solrconfig.xml file.
   * Be sure to have replicateAfter 'commit' setup on repeater even if replicateAfter is set
to optimize on the main master. This is because on a repeater (or any slave), only a commit
is called after index is downloaded. Optimize is never called on slaves.

Mime
View raw message