lucene-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Erick Erickson (Confluence)" <conflue...@apache.org>
Subject [CONF] Apache Solr Reference Guide > Solr Cores and solr.xml
Date Mon, 22 Jul 2013 22:54:00 GMT
Space: Apache Solr Reference Guide (https://cwiki.apache.org/confluence/display/solr)
Page: Solr Cores and solr.xml (https://cwiki.apache.org/confluence/display/solr/Solr+Cores+and+solr.xml)


Edited by Erick Erickson:
---------------------------------------------------------------------
[Format of solr.xml]
[Legacy solr.xml Configuration]
[Moving to the New solr.xml Format]
[CoreAdminHandler Parameters and Usage]

{section}
{column:width=75%}

{note}
In Solr 4.3, a new structure for {{solr.xml}} has been introduced. This structure will become
mandatory as of Solr 5.0.

This structure can be used in Solr 4.3 and higher. Solr 4.4 will ship with the new structure
as the default example.
{note}
{column}

{column:width=25%}
{panel}
Covered in this section:
{toc:maxLevel=2}
{panel}
{column}
{section}

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:

{code:xml|borderStyle=solid|borderColor=#666666}
<solr persistent="true">
  <cores adminPath="/admin/cores" defaultCoreName="collection1" host="${host:}"
         hostPort="${jetty.port:}" hostContext="${hostContext:}"
         zkClientTimeout="${zkClientTimeout:15000}">
    <core name="collection1" instanceDir="collection1" />
  </cores>
</solr>
{code}

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

h2. 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:

{code:xml|borderStyle=solid|borderColor=#666666}
<solr persistent="false">
  <cores adminPath="/admin/cores" host="${host:}" hostPort="${jetty.port:}">
    <core name="core0" instanceDir="core0" />
    <core name="core1" instanceDir="core1" />
  </cores>
</solr>
{code}

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.

{info}
You can run Solr without configuring any cores.
{info}

h2. Solr.xml Parameters

h3. The {{<solr>}} Element

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

|| Attribute || Description ||
| persistent | Indicates 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. |
| sharedLib | Specifies 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. |

{note}
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.
{note}

h3. 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.

|| Attribute || Description ||
| adminPath | This 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. |
| host | The hostname Solr uses to access cores. |
| hostPort | The 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. |
| hostContext | The servlet context path. |
| zkClientTimeout | A timeout for connection to a ZooKeeper server. It is used with [solr:SolrCloud].
|
| defaultCoreName | The name of a core that will be used for requests that do not specify
a core. |
| transientCacheSize | Defines how many cores with {{transient=true}} that can be loaded before
swapping the least recently used core for a new core. |
| shareSchema | This 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}}. |
| adminHandler | If 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].
|

h3. The <core> Element

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

|| Attribute || Description ||
| name | The name of the SolrCore.  You'll use this name to reference the SolrCore when running
commands with the CoreAdminHandler. |
| instanceDir | This relative path defines the Solr Home for the core. |
| config | The configuration file name for a given core. The default is {{solrconfig.xml}}.
|
| schema | The schema file name for a given core. The default is {{schema.xml}} |
| dataDir | This relative path defines the Solr Home for the core. |
| properties | The name of the properties file for this core. The value can be an absolute
pathname or a path relative to the value of {{instanceDir}}. |
| transient | If *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. |
| loadOnStartup | If *true*, the default if it is not specified, the core will loaded when
Solr starts. |
| coreNodeName | Added 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. |

h3. 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.

{code:borderStyle=solid|borderColor=#666666}
<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"/>
    </cores>
</solr>
{code}

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:

|| Property || Description ||
| solr.core.name | The core's name, as defined by the "name" attribute. |
| solr.core.instanceDir | The core's instance directory under which that its {{conf/}} and
{{data/}} directories are located, derived from the core's {{instanceDir}} attribute. |
| solr.core.dataDir | The core's data directory, {{$\{solr.core.instanceDir\}/data}} by default.
|
| solr.core.configName | The name of the core's configuration file, {{solrconfig.xml}} by
default. |
| solr.core.schemaName | The 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:

Without a default value, result will be empty if the property is not defined:

{{$\{productname\}}}

With a default value:

{{$\{productname:SearchCo MegaIndex\}}}



{scrollbar}


Stop watching space: https://cwiki.apache.org/confluence/users/removespacenotification.action?spaceKey=solr
Change email notification preferences: https://cwiki.apache.org/confluence/users/editmyemailsettings.action


    

Mime
View raw message