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 JohnBennett: http://wiki.apache.org/solr/SolrReplication ------------------------------------------------------------------------------ <!> ["Solr1.4"] = Features = - * Replication w/o external scripts + * Replication without requiring external scripts * Configuration in solrconfig.xml only * Replicates configuration files also * Works across platforms with same configuration @@ -29, +29 @@ }}} '''Note:''' - * 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 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 '''startup''' option is given replication will not be triggered on subsequent commits/optimizes after it is done for the first time at the start. + * 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 ==== - In the master configuration + 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> }}} - This ensures that 'solrconfig_slave.xml' will be saved as 'solrconfig.xml' on the slave. All other files will be saved in their original names. + This ensures that the local configuration 'solrconfig_slave.xml' will be saved as 'solrconfig.xml' on the slave. All other files will be saved with their original names. - The file name can be anything in the master, and it will be saved as the name after the colon ':'. + 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 ':'. === in slave: === {{{ @@ -77, +77 @@ 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 === - 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 some of the slaves as repeaters. A repeater is simply a node that acts as both a master and a slave. + 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. + * 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. @@ -86, +86 @@ This shows the following information * status of current replication - * percentage/size dowloaded/to be downloaded + * percentage/size downloaded/to be downloaded * Current file being downloaded - * Time taken/ Time remaining + * Time taken/Time remaining The following actions can be performed from the dashboard * Enable/Disable polling @@ -97, +97 @@ = How does it work ? = - This feature relies on the !IndexDeletionPolicy feature of Lucene. Lucene exposes the different !IndexCommits and the files associated w/ that commit through this API. This enables us to quickly identify the files that need to be downloaded. + This feature relies on the !IndexDeletionPolicy feature of Lucene. Through this API, Lucene exposes !IndexCommits requests, along with the files associated with each commit. This exposures enables us to quickly identify the files that need to be downloaded. True to the tradition of Solr, all operations are performed over a REST API. The !ReplicationHandler exposes a REST API for discovering the current index version and the files (and their metadata) associated with each version. The slave uses this API to discover the new files in the master's index. The slave then determines which of those files need to be downloaded from the master. It sends a request (using HTTP GET) to the master for the content of each file. This uses a custom format (akin to the HTTP chunked encoding) to download the full content or a part of each file. The slave stores downloaded files in a temp directory. Once all the required files are downloaded, the slave moves all the files to the index directory and issues a 'commit' command.
