Dear Wiki user, You have subscribed to a wiki page or wiki category on "Solr Wiki" for change notification.
The "SolrReplication" page has been changed by FredDrake. The comment on this change is: more typo fixes. http://wiki.apache.org/solr/SolrReplication?action=diff&rev1=66&rev2=67 -------------------------------------------------- * Force start replication * Abort an ongoing replication - = How does it work ? = + = How does it work? = This feature relies on the [[http://hudson.zones.apache.org/hudson/job/Lucene-trunk/javadoc/core/org/apache/lucene/index/IndexDeletionPolicy.html|IndexDeletionPolicy]] feature of Lucene. Through this API, Lucene exposes [[http://hudson.zones.apache.org/hudson/job/Lucene-trunk/javadoc/core/org/apache/lucene/index/IndexCommit.html|IndexCommits]] as callbacks for each commit/optimize. An [[http://hudson.zones.apache.org/hudson/job/Lucene-trunk/javadoc/core/org/apache/lucene/index/IndexCommit.html|IndexCommit]] exposes the files associated with each commit. This enables us to identify the files that need to be replicated. @@ -129, +129 @@ == What happens when I commit or optimize? == When a commit/optimize is done on master, !ReplicationHandler reads the list of file names which are associated with each commit point. This relies on the 'replicateAfter' parameter in the configuration to decide when these file names are to be fetched and stored from Lucene. - == How does the slave replicate ? == + == How does the slave replicate? == The master is totally unaware of the slaves. The slave continuously keeps polling the master (depending on the 'pollInterval' parameter) to check the current index version the master. If the slave finds out that the master has a newer version of the index it initiates a replication process. The steps are as follows, @@ -140, +140 @@ * A 'commit' command is issued on the slave by the Slave's !ReplicationHandler and the new index is loaded. - == How are configuration files replicated ? == + == How are configuration files replicated? == * The files that are to be replicated have to be mentioned explicitly in using the 'confFiles' parameter. - * Only files in the 'conf' dir of solr instance is replicated. + * Only files in the 'conf' dir of the solr instance are replicated. - * The files are replicated only along with a fresh index. That means even if a file is changed in the master the file is replicated only after there is a new commit/optimize on master + * The files are replicated only along with a fresh index. That means even if a file is changed in the master the file is replicated only after there is a new commit/optimize on the master. - * Unlike the index files ,where the timestamp is good enough to figure out if they are identical, conf files are compared against their checksum .The schema.xml files (on master and slave) are same if their checksume is same. + * Unlike the index files, where the timestamp is good enough to figure out if they are identical, conf files are compared against their checksum. The schema.xml files (on master and slave) are same if their checksums match. - * Conf files are also downloaded to a temp dir before they are 'mov'ed to the original files .The old files are renamed and kept in the same direcory. !ReplicationHandler does not automatically clean up these old files. + * Conf files are also downloaded to a temp dir before they are 'mov'ed to the original files. The old files are renamed and kept in the same directory. !ReplicationHandler does not automatically clean up these old files. * If a replication involved downloading of at least one conf file a core reload is issued instead of a 'commit' command. - == What if I add documents to the slave or if slave index gets corrupted ? == + == What if I add documents to the slave or if slave index gets corrupted? == - If docs are added to the slave , then the slave is not in sync with the master anymore. But , it does not do anything to keep it in sync with master till the master has a newer index. When a commit happens on the master then the index version of the master will become different from that of the slave. The slave fetches the list of files and finds that some of the files (same name) are there in the local index with a different size/timestamp. This means that the master and slave have incompatible indexes. Slave then copies all the files from master (there may be scope to optimize this, but this is a rare case and may not be worth it) to a new index dir and and asks the core to load the fresh index from the new directory. + If docs are added to the slave, then the slave is not in sync with the master anymore. But, it does not do anything to keep it in sync with master until the master has a newer index. When a commit happens on the master, the index version of the master will become different from that of the slave. The slave fetches the list of files and finds that some of the files (same name) are there in the local index with a different size/timestamp. This means that the master and slave have incompatible indexes. Slave then copies all the files from master (there may be scope to optimize this, but this is a rare case and may not be worth it) to a new index dir and and asks the core to load the fresh index from the new directory. == HTTP API == @@ -185, +185 @@ </lst> </requestHandler> }}} - When the master is started, pass in -Denable.master=true and in the slave pass in -Denable.slave=true. Alternately , these values can be stored in a solrcore.properties file as follows + When the master is started, pass in -Denable.master=true and in the slave pass in -Denable.slave=true. Alternately, these values can be stored in a solrcore.properties file as follows: {{{ #solrcore.properties in master enable.master=true
