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 2009/08/15 09:19:59 UTC

[Solr Wiki] Update of "SolrReplication" by HossMan

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.