Legacy solr.xml Configuration

  categories:搜索资料  tags:,   author:



Use solr.xml to configure your Solr core (a logical index and associated configuration files), or to configure multiple cores. You can find solr.xml in your Solr Home directory. The default solr.xml file looks like this:

<solr persistent="true">
<cores adminPath="/admin/cores" defaultCoreName="collection1" host="${host:}"
hostPort="${jetty.port:}" hostContext="${hostContext:}"
<core name="collection1" instanceDir="collection1" />

For more information about core configuration and solr.xml, see http://wiki.apache.org/solr/CoreAdmin.

Using Multiple SolrCores

It is possible to segment Solr into multiple cores, each with its own configuration and indices. Cores may be dedicated to a single application or to very different ones, but all are administered through a common administration interface. You can create new Solr cores on the fly, shutdown cores, even replace one running core with another, all without ever stopping or restarting your servlet container.

Solr cores are configured by placing a file named solr.xml in your solr.home directory. A typical solr.xml looks like this:

<solr persistent="false">
<cores adminPath="/admin/cores" host="${host:}" hostPort="${jetty.port:}">
<core name="core0" instanceDir="core0" />
<core name="core1" instanceDir="core1" />

This sets up two Solr cores, named “core0″ and “core1″, and names the directories (relative to the Solr installation path) which will store the configuration and data sub-directories.

You can run Solr without configuring any cores.

Solr.xml Parameters

The <solr> Element

There are several attributes that you can specify on <solr>, which is the root element of solr.xml.

coreLoadThreadsSpecifies the number of threads that will be assigned to load cores in parallel
persistentIndicates that changes made through the API or admin UI should be saved back to this solr.xml. If not true, any runtime changes will be lost on the next Solr restart. The servlet container running Solr must have sufficient permissions to replace solr.xml (file delete and create), or errors will result. Any comments in solr.xml are not preserved when the file is updated. The default is true.
sharedLibSpecifies the path to a common library directory that will be shared across all cores. Any JAR files in this directory will be added to the search path for Solr plugins. This path is relative to the top-level container’s Solr Home.
zkHostIn SolrCloud mode, the URL of the ZooKeeper host that Solr should use for cluster state information.
If you set the persistent attribute to true, be sure that the Web server has permission to replace the file. If the permissions are set incorrectly, the server will generate 500 errors and throw IOExceptions. Also, note that any comments in the solr.xml file will be lost when the file is overwritten.

The <cores> Element

The <cores> element, which contains definitions for each Solr core, is a child of <solr> and accepts several attributes of its own.

adminPathThis is the relative URL path to access the SolrCore administration pages. For example, a value of /admin/cores means that you can access the CoreAdminHandler with a URL that looks like this: http://localhost:8983/solr/admin/cores. If this attribute is not present, then SolrCore administration will not be possible.
hostThe hostname Solr uses to access cores.
hostPortThe port Solr uses to access cores. In the default solr.xml file, this is set to ${jetty.port:}, which will use the Solr port defined in Jetty.
hostContextThe servlet context path.
zkClientTimeoutA timeout for connection to a ZooKeeper server. It is used with SolrCloud.
distribUpdateConnTimeoutUsed to set the underlying “connTimeout” for intra-cluster updates.
distribUpdateSoTimeoutUsed to set the underlying “socketTimeout” for intra-cluster updates
leaderVoteWaitWhen SolrCloud is starting up, how long each Solr node will wait for all known replicas for that share to be found before assuming that any nodes that haven’t reported are down.
genericCoreNodeNamesIf TRUE, node names are not based on the address of the node, but on a generic name that identifies the core. When a different machine takes over serving that core things will be much easier to understand.
managementPathno-op at present.
defaultCoreNameThe name of a core that will be used for requests that do not specify a core.
transientCacheSizeDefines how many cores with transient=true that can be loaded before swapping the least recently used core for a new core.
shareSchemaThis attribute, when set to true, ensures that the multiple cores pointing to the same schema.xml will be referring to the same IndexSchema Object. Sharing the IndexSchema Object makes loading the core faster. If you use this feature, make sure that no core-specific property is used in your schema.xml.
adminHandlerIf used, this attribute should be set to the FQN (Fully qualified name) of a class that inherits from CoreAdminHandler. For example, adminHandler="com.myorg.MyAdminHandler" would configure the custom admin handler (MyAdminHandler) to handle admin requests. If this attribute isn’t set, Solr uses the default admin handler, org.apache.solr.handler.admin.CoreAdminHandler. For more information on this parameter, see the Solr Wiki at http://wiki.apache.org/solr/CoreAdmin#cores.

The <logging> Element

There is at most one <logging> element for a Solr installation that defines various attributes for logging.

classThe class to use for logging. The corresponding JAR file must be available to solr, perhaps through a <lib> directive in solrconfig.xml.
enabledtrue/false – whether to enable logging or not.

In addition, the <logging> element may have a child element <watcher> which may have the following attributes

sizeThe number of log events that are buffered.
thresholdThe logging level above which your particular logging implementation will record. For example when using log4j one might specify DEBUG or WARN or INFO etc.

The <core> Element

There is one <core> element for each SolrCore you define. They are children of the <cores> element and each one accepts the following attributes.

nameThe name of the SolrCore. You’ll use this name to reference the SolrCore when running commands with the CoreAdminHandler.
instanceDirThis relative path defines the Solr Home for the core.
configThe configuration file name for a given core. The default is solrconfig.xml.
schemaThe schema file name for a given core. The default is schema.xml
dataDirThis relative path defines the Solr Home for the core.
propertiesThe name of the properties file for this core. The value can be an absolute pathname or a path relative to the value of instanceDir.
transientIf true, the core can be unloaded if Solr reaches the transientCacheSize. The default if not specified is false. Cores are unloaded in order of least recently used first.
loadOnStartupIf true, the default if it is not specified, the core will loaded when Solr starts.
coreNodeNameAdded in Solr 4.2, this attributes allows naming a core. The name can then be used later if you need to replace a machine with a new one. By assigning the new machine the same coreNodeName as the old core, it will take over for the old SolrCore.
ulogDirThe absolute or relative directory for the update log for this core (SolrCloud)
shardThe shard to assign this core to (SolrCloud)
collectionThe name of the collection this core is part of (SolrCloud)
rolesFuture param for SolrCloud or a way for users to mark nodes for their own use.

Properties in solr.xml

You can define properties in solr.xml that you may then reference in solrconfig.xml and schema.xml. Properties are name/value pairs. The scope of a property depends on which element it occurs within.

If a property is declared under <solr> but outside a <core> element, then it will have container scope and will be visible to all cores. In the example above, productname is such a property.

If a property declaration occurs within a <core> element, then its scope is limited to that core and it will not be visible to other cores. A property at core scope will override one of the same name declared at container scope.

<solr persistent="true" sharedLib="lib">
<property name="productname" value="Acme Online"/>
<cores adminPath="/admin/cores">
<core name="core0" instanceDir="core0">
<property name="dataDir" value="/data/core0"/></core>
<core name="core1" instanceDir="core1"/>

In addition to any properties you declare at the core level, there are several properties that Solr defines automatically for each core. These properties are described in the table below:

solr.core.nameThe core’s name, as defined by the “name” attribute.
solr.core.instanceDirThe core’s instance directory under which that its conf/ and data/ directories are located, derived from the core’s instanceDir attribute.
solr.core.dataDirThe core’s data directory, ${solr.core.instanceDir}/data by default.
solr.core.configNameThe name of the core’s configuration file, solrconfig.xml by default.
solr.core.schemaNameThe name of the core’s schema file, schema.xml by default.

Any of the above properties can be referenced by name in schema.xml or solrconfig.xml.

When defining properties, you can assign a property a default value that will be used if another value isn’t specified. For example:

<!-- Blank unless company.name variable is defined -->
<str name="foo">${company.name}</str>
<!-- "SearchCo MegaIndex" if company.name variable is not defined -->
<str name="bar">${some.variable.name:SearchCo MegaIndex}</str>

快乐成长 每天进步一点点