Solr是一个独立的企业级搜索应用服务器，Solr是一个高性能，采用Java5开发，基于Lucene的全文搜索服务器。同时对其进行了扩展，提供了比Lucene更为丰富的查询语言，同时实现了可配置、可扩展并对查询性能进行了优化，并且提供了一个完善的功能管理界面，是一款非常优秀的全文搜索引擎。
来源:https://cwiki.apache.org/confluence/display/solr/Moving+to+the+New+solr.xml+Format
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.
Startup
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 core.properties file. This file can be empty if all defaults are acceptable. In particular, the instanceDir is assumed to be the directory in which the core.properties 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 core.properties file was discovered.
As mentioned elsewhere, the tree structure that the cores are in is arbitrary, with the exception that the directories containing the core.properties 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 core.properties file is discovered. Siblings of the directory in which the core.properties file is discovered are still walked, only stopping recursing down the sibling when a core.properties file is found.
Example
Here's an example of what a legacy solr.xml file might look like and the equivalent discovery-based solr.xml and core.properties files:
<solr persistent="${solr.xml.persist:false}"> <cores adminPath="/admin/cores" defaultCoreName="collection1" host="127.0.0.1" hostPort="${hostPort:8983}" hostContext="${hostContext:solr}" zkClientTimeout="${solr.zkclienttimeout:30000}" shareSchema="${shareSchema:false}" genericCoreNodeNames="${genericCoreNodeNames:true}"> <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> </shardHandlerFactory> </cores></solr> |
The new-style solr.xml might look like what is below. Note that adminPath, defaultCoreName are not supported in discovery-based solr.xml.
<solr> <solrcloud> <str name="host">127.0.0.1</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> </solrcloud> <shardHandlerFactory name="shardHandlerFactory" class="HttpShardHandlerFactory"> <int name="socketTimeout">${socketTimeout:120000}</int> <int name="connTimeout">${connTimeout:15000}</int> </shardHandlerFactory> |
In each of "core1" and "core2" directories, there would be a core.properties file that might look like these. Note that note that instanceDir is not supported, it is assumed to be the directory in which core.properties is found.
core1:
name=core1shard=${shard:}collection=${collection:core1}config=${solrconfig:solrconfig.xml}schema=${schema:schema.xml}coreNodeName=${coreNodeName:} |
core2:
name=core2 |
In fact, the core2 core.properties file could even be empty and the name would default to the directory in which the core.properties file was found.
Labels:
- 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 core.properties 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.).
