Configure multicore in solr4.4

I am new to SOLR, so I am not familiar with many things. Here I just record my learning process.

References:

• Http://wiki.apache.org/solr/Solr.xml%204.4%20and%20beyond
• Http://wiki.apache.org/solr/Core%20Discovery%20%284.4%20and%20beyond%29
• Http://wiki.apache.org/solr/CoreAdmin

This article mainly describes the differences between solr4.4 and the old version in the multicore configuration. Therefore, many official documents have been referenced, because I am new to SOLR and have a low level, therefore, the description may not be clear. If you have any questions, please go to the official wiki document listed above.

Introduction to SOLR multicore

For details about SOLR multicore, refer to the official wiki page:

Http://wiki.apache.org/solr/CoreAdmin

There are several statements on this Wiki to introduce SOLR multicore:

In SOLR, the "multi core" concept refers to the ability to have multiple cores running in the same webapp.

Multiple cores let you have a single SOLR instance with separate deployments and indexes, with their own config and schema for very different applications, but still have the convenience of unified
Administration. individual indexes are still fairly isolated, but you can manage them as a single application, create new indexes on the fly by spinning up new solrcores, and even make one solrcore replace another solrcore without ever restarting your Servlet
Container.

If your English is not good, I will not try to translate it. You can see the general meaning. Multicore is added to solr1.3 to run a SOLR instance that can have multiple search applications (this is what others say, reference it ).

Multicore in solr4.4

In versions earlier than solr4.4, all multicores are in % solr_home %/SOLR. although I have not used earlier SOLR versions configured in XML, it can be seen from some online tutorials. For example:

• Http://blog.chenlb.com/2009/01/try-solr-multicore.html
• Http://blog.csdn.net/jiushuai/article/details/8080758

The general configuration is as follows:

<cores adminPath="/admin/cores">      <core name="core0" instanceDir="core0" />      <core name="core1" instanceDir="core1" /></cores> 

However, the multicore changes in solr4.4 are very large compared with previous versions. These changes can be seen on the following two pages:

• Http://wiki.apache.org/solr/Solr.xml%204.4%20and%20beyond
• Http://wiki.apache.org/solr/Core%20Discovery%20%284.4%20and%20beyond%29

From the above page, we can see that from solr4.4, The SOLR. XML structure under % solr_home % has changed, and these changes will be enforced in 5.0. The following is an introduction to the official wiki:

• Optionally as of solr4.4 and mandatory for solr5.0,
  The structure of the SOLR. XML file has changed. in a nutshell, <cores> and <core> have been replaced by auto-discovering cores. whether to use old or new-style core definitions is determined by whether the <cores> tag is present in SOLR. XML. in 5.0, presence
  Of the <cores> tag will generate an error on startup.

• An optional PropertyCorerootdirectoryCan cause the discovery process to start at an arbitrary directory other than solr_home.

• We'll distribute a new-style SOLR. XML as the default in the example directory with solr4.4

• TheSharedlibAttribute on the top-level<SOLR>Element is replaced by a childStrElement (see below). In theory, the old mechanic shocould continue to supportSharedlib,
  But SOLR-4791 documents the fact that it doesn't work in 4.3.0.

In the above paragraphs, the general meaning is from solr4.4 in SOLR. the <cores/> node is removed from the XML file and replaced by the automatic detection cores. This change is optional in solr4.4, and is mandatory from solr5.0.

Automatic detection of multicore in solr4.4

So how does SOLR automatically detect cores? Wiki also has related descriptions:

Core discovery process

Condition of the core tree terminates when a file named core. properties is encountered. Discovery of a file of that name is assumed to define the root of a core. There is no a-priori limit
On the depth of the tree. that is, the directories under the core root are pinned ed until a core. properties file is encountered, and that directory is assumed to be the instancedir for that core. subdirectories of any directory that has a core. properties File
Are not examined for additional cores.

From the above introduction, we can see that the test will start from core root (core root can be in SOLR. in the XML file, it is defined by the corerootdirectory attribute), recursively traversing all its subdirectories without limit until a file named core. properties configuration file is found. The directory containing the core. properties file will be treated as the instancedir directory of the core, and the subdirectory under the directory will not be treated as the instancedir of another core even if it contains the core. properties file.

So what information can be configured in the core. properties file? As follows:

• Name-the name of the core. If not specified, the name comes from the containing directory.
• Config-the configuration file. defaults to solrconfig. xml
• Datadir-the directory where the index, tlog, etc. are stored. Again, since this is discovery-based, omit this unless you have special needs.
• Ulogdir-where the transaction log resides. It may be advantageous to put the transaction lot on a different disk than the index.
• Schema-the schema file. defaults to schema. xml
• Shard-the shard ID.
• Collection-the collection to which this core belongs

• Roles-solrcloud Role Definition

• Properties-properties file to override core definitions. TBD: This is probably obsolete since we're re reading a properties file in the first place. Is there a use case for supporting this now?

• Loadonstartup -[True| False] This core shoshould be loaded and a searcher opened When SOLR starts.

• Transient-[true |False] This core may be unloaded if the core cache exceeds transientcachesize (defined in SOLR. propreties)

• Corenodename-solrcloud core node name

All the configuration items have corresponding explanations, which are also very simple. I will not explain them much here.

• Note 1: If the core. properties file is empty, that is, there is no text in it, the core name will be the same as the Directory Name of the core. properties file. For example, an empty core. the properties file appears in the/SOLR/home/core1 directory. The default core name is "core1" and instancedir is/SOLR/home/core1, datadir is the/SOLR/home/core1/data directory.
• NOTE 2: it is easy to imagine that if you want to temporarily ignore a core, the simplest way is to set the core in the instancedir directory corresponding to the core. rename the properites file, such as core. properties. bak.
• Note 3: The cores node in SOLR. xml of solr4.4 is optional, that is, dispensable. Whether the cores node is included will be used as the SOLR. XML is parsed according to the new style or the old style. the cores node configured in the XML file is stored in the instancedir directory with core. properties file, then SOLR. the configuration in the XML file takes precedence.

Instance Configuration

The previous content is an empty theory. Let's take a look at your configuration.

My solr_home is defined in the/opt/tomcat-6.0.37/webapps/SOLR/solr_home directory. The directory structure is as follows:

The <cores/> node is not defined in my SOLR. xml file, so SOLR. XML will be parsed as a configuration file of the new style, that is, SOLR will automatically detect the definition of cores. In addition, the collection1 and core1 subdirectories under this directory contain core. properties configuration file, in which core under core1 directory. the properties file is empty. The core in the collection1 directory. the properties file has only one line of content:

Name = core0

It is worth noting that the directory structures of collection1 and core1 are similar. The difference is only the core. properties file and the schema. xml configuration file. The directory structure is roughly as follows:

According to the above introduction, the collection1 and core1 directories are regarded as core instancedir, and the two cores are named core0 and core1.

Start Tomcat. when accessing the browser, you can see that there are two cores in the core selection list, core0 and core1, respectively. paste an image to verify: