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.