SOLR Master-Slave cluster configuration brief description

The clusters of SOLR are mainly divided into master-slave and Solrcloud two kinds. Master and slave, more suitable to read the main scene. Solrcloud is suitable for large data volumes and is updated from time to time. Then SOLR's master-slave configuration is simple. Find <requesthandler name= "/replication" class= "Solr in Solrconfig.xml. Replicationhandler ">. The replication here mainly solves the master-slave replication. It mainly implements: the data writes in the main, reads the operation in the slave node. When the concurrency is larger, you can expand the number of slave nodes to deal with, multiple slave do a reverse proxy and load balancing (in this article, do not explain, if necessary, can use Nginx or Apache and other load software), for query use. Okay, first look at the Master node configuration:

  <requesthandler name= "/replication" class= "SOLR. Replicationhandler ">     <!--       to enable simple master/slave replication, uncomment one of the        sections Below, depending on whether this SOLR instance should is       the "master" or a "slave".  If This instance are a "slave" you'll        also need to fill in the MasterUrl-to-point-a real machine.    --       <lst name= "Master" >         <str name= "Replicateafter" >commit</str>         <str name= " Replicateafter ">startup</str>         <str name=" Conffiles ">schema.xml,stopwords.txt,spellings.txt, synonyms.txt</str>       </lst>    <!--       <lst name= "slave" >         <str name= " MasterUrl ">http://your-master-hostname:8983/solr</str>         <str name=" PollInterval ">00:00:60 </str>       </lst>    -

　　

master flag the core as the primary node. The behavior of replication occurs after a commit, startup. Coffiles indicates that the configuration file to be copied from the node (remember, the master-slave solrconfig.xml configuration is not the same, do not copy the solrconfig.xml to the slave node). 
 
 Looking at the configuration of the slave node, the slave configuration is simple, commenting out the master section of the above configuration file. Let's get slave that part. Replace the masterurl with the master URL in the format: Http://your-master-host:port/solr/your_core_name. The specific configuration is as follows: 

<requesthandler name= "/replication" class= "SOLR. Replicationhandler ">     <!--       to enable simple master/slave replication, uncomment one of the        sections Below, depending on whether this SOLR instance should is       the "master" or a "slave".  If This instance are a "slave" you'll        also need to fill in the MasterUrl-to-point-a real machine.    -    <!--       <lst name= "Master" >         <str name= "Replicateafter" >commit</str>         <str name= "Replicateafter" >startup</str>         <str name= "Conffiles" >schema.xml,stopwords.txt </str>       </lst>          <lst name= "slave" >         <str name= "MasterUrl" >http:/ /192.9.104.116:8090/solr/poi</str>         <str name= "PollInterval" >00:00:20</str>       </lst >    </requestHandler>

　　

PollInterval indicates how often the data is synchronized to master, and the data format {}:{minutes}:{seconds}. This is based on your business scenario. If the update is more frequent, turn this value down, or vice versa, make it bigger. When synchronizing data, depending on the network and machine configuration, the data between the slave will be out of sync with each other. If you have a request for this, you need to be aware of it. In short, any kind of clustering scheme is not omnipotent. SOLR's master-slave model currently has a number of problems, such as: The main node has a single point of failure and so on, I hope the subsequent version will be some improvements.

SOLR Master-Slave cluster configuration brief description