Moving to the New solr.xml Format

  categories:搜索资料  tags:,   author:



Migration from old-style solr.xml to core discovery is very straightforward. First, modify the solr.xml file from the legacy format to the discovery format.

In general there is a direct analog from the legacy format to the new format except there is no <cores> element nor are there any <core> elements in discovery-based Solr.


In Solr 4.4 and on, the presence of a <cores> child element of the <solr> element in the solr.xml file signals a legacy version of solr.xml, and cores are expected to be defined as they have been historically. Depending on whether a <cores> element is discovered, solr.xml is parsed as either a legacy or discovery file and errors are thrown in the log if legacy and discovery modes are mixed in solr.xml.

Moving <core> definitions.

To migrate to discovery-based solr.xml, remove all of the <core> elements and the enclosing <cores> element from solr.xml. See the pages linked above for examples of migrating other attributes. Then, in the instanceDir for each core create a file. This file can be empty if all defaults are acceptable. In particular, the instanceDir is assumed to be the directory in which the file is discovered. The data directory will be in a directory called “data” directly below. If the file is completely empty, the name of the core is assumed to be the name of the folder in which the file was discovered.

As mentioned elsewhere, the tree structure that the cores are in is arbitrary, with the exception that the directories containing the files must share a common root, but that root may be many levels up the tree. Note that supporting a root for the cores that is not a child of SOLR_HOME is supported through properties in solr.xml. However, only one root is possible, there is no provision presently for specifying multiple roots.

The only restriction on the tree structure is that cores may not be children of other cores; enumeration stops descending down the tree when the first file is discovered. Siblings of the directory in which the file is discovered are still walked, only stopping recursing down the sibling when a file is found.


Here’s an example of what a legacy solr.xml file might look like and the equivalent discovery-based solr.xml and files:

<solr persistent="${solr.xml.persist:false}">
<cores adminPath="/admin/cores" defaultCoreName="collection1" host="" hostPort="${hostPort:8983}"
hostContext="${hostContext:solr}" zkClientTimeout="${solr.zkclienttimeout:30000}" shareSchema="${shareSchema:false}"
<core name="core1" instanceDir="core1" shard="${shard:}" collection="${collection:core1}" config="${solrconfig:solrconfig.xml}" schema="${schema:schema.xml}" coreNodeName="${coreNodeName:}"/>
<core name="core2" instanceDir="core2" />
<shardHandlerFactory name="shardHandlerFactory" class="HttpShardHandlerFactory">
<int name="socketTimeout">${socketTimeout:120000}</int>
<int name="connTimeout">${connTimeout:15000}</int>

The new-style solr.xml might look like what is below. Note that adminPath, defaultCoreName are not supported in discovery-based solr.xml.

<str name="host"></str>
<int name="hostPort">${hostPort:8983}</int>
<str name="hostContext">${hostContext:solr}</str>
<int name="zkClientTimeout">${solr.zkclienttimeout:30000}</str>
<str name="shareSchema">${shareSchema:false}</str>
<str name="genericCoreNodeNames">${genericCoreNodeNames:true}</str>
<shardHandlerFactory name="shardHandlerFactory" class="HttpShardHandlerFactory">
<int name="socketTimeout">${socketTimeout:120000}</int>
<int name="connTimeout">${connTimeout:15000}</int>

In each of “core1″ and “core2″ directories, there would be a file that might look like these. Note that note that instanceDir is not supported, it is assumed to be the directory in which is found.





In fact, the core2 file could even be empty and the name would default to the directory in which the file was found.


  • The content here is mostly fine in terms of description, although if you really wanted to go for it, perhaps take a simple solr.xml file from Solr 4.3 (2 shards, maybe) and show what the solr.xml and would look like and where they should go. That could wait for next release, however if time is tight. If I have time tonight or tomorrow, I will take a stab at it.
  • See also other comments I’ve made about h1 headers and monospaced text (on Format of solr.xml, for example).
  • At the bottom of the content, add the {scrollbar} macro for consistency with other pages – it adds page navigation (prev, next, etc.).

快乐成长 每天进步一点点