Defining core.properties | Apache Solr Reference Guide 6.6

Core discovery means that creating a core is as simple as a core.properties file located on disk.

The core.properties file is a simple Java Properties file where each line is just a key=value pair, e.g., name=core1. Notice that no quotes are required.

A minimal core.properties file looks like the example below. However, it can also be empty, see information on placement of core.properties below.

name=my_core_name

Placement of core.properties

Solr cores are configured by placing a file named core.properties in a sub-directory under solr.home. There are no a-priori limits to the depth of the tree, nor are there limits to the number of cores that can be defined. Cores may be anywhere in the tree with the exception that cores may not be defined under an existing core. That is, the following is not allowed:

./cores/core1/core.properties
./cores/core1/coremore/core5/core.properties

In this example, the enumeration will stop at "core1".

The following is legal:

./cores/somecores/core1/core.properties
./cores/somecores/core2/core.properties
./cores/othercores/core3/core.properties
./cores/extracores/deepertree/core4/core.properties

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

Your core.properties file can be empty if necessary. Suppose core.properties is located in ./cores/core1 (relative to solr_home) but is empty. In this case, the core name is assumed to be "core1". The instanceDir will be the folder containing core.properties (i.e., ./cores/core1). The dataDir will be ../cores/core1/data, etc.

You can run Solr without configuring any cores.

Defining core.properties Files

The minimal core.properties file is an empty file, in which case all of the properties are defaulted appropriately.

Java properties files allow the hash (#) or bang (!) characters to specify comment-to-end-of-line.

This table defines the recognized properties:

Property Description

Property	Description
`name`	The name of the SolrCore. You’ll use this name to reference the SolrCore when running commands with the CoreAdminHandler.
`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` but please note that if you are using a "managed schema" (the default behavior) then any value for this property which does not match the effective `managedSchemaResourceName` will be read once, backed up, and converted for managed schema use. See Schema Factory Definition in SolrConfig for details.
`dataDir`	The core’s data directory (where indexes are stored) as either an absolute pathname, or a path relative to the value of `instanceDir`. This is `data` by default.
`configSet`	The name of a defined configset, if desired, to use to configure the core (see the Config Sets for more details).
`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. Setting to true* is not recommended in SolrCloud mode.*
`loadOnStartup`	If true, the default if it is not specified, the core will loaded when Solr starts. Setting to false* is not recommended in SolrCloud mode.*
`coreNodeName`	Used only in SolrCloud, this is a unique identifier for the node hosting this replica. By default a coreNodeName is generated automatically, but setting this attribute explicitly allows you to manually assign a new core to replace an existing replica. For example: when replacing a machine that has had a hardware failure by restoring from backups on a new machine with a new hostname or port..
`ulogDir`	The absolute or relative directory for the update log for this core (SolrCloud).
`shard`	The shard to assign this core to (SolrCloud).
`collection`	The name of the collection this core is part of (SolrCloud).
`roles`	Future param for SolrCloud or a way for users to mark nodes for their own use.

name

The name of the SolrCore. You’ll use this name to reference the SolrCore when running commands with the CoreAdminHandler.

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 but please note that if you are using a "managed schema" (the default behavior) then any value for this property which does not match the effective managedSchemaResourceName will be read once, backed up, and converted for managed schema use. See Schema Factory Definition in SolrConfig for details.

dataDir

The core’s data directory (where indexes are stored) as either an absolute pathname, or a path relative to the value of instanceDir. This is data by default.

configSet

The name of a defined configset, if desired, to use to configure the core (see the Config Sets for more details).

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. Setting to true is not recommended in SolrCloud mode.

loadOnStartup

If true, the default if it is not specified, the core will loaded when Solr starts. Setting to false is not recommended in SolrCloud mode.

coreNodeName

Used only in SolrCloud, this is a unique identifier for the node hosting this replica. By default a coreNodeName is generated automatically, but setting this attribute explicitly allows you to manually assign a new core to replace an existing replica. For example: when replacing a machine that has had a hardware failure by restoring from backups on a new machine with a new hostname or port..

ulogDir

The absolute or relative directory for the update log for this core (SolrCloud).

shard

The shard to assign this core to (SolrCloud).

collection

The name of the collection this core is part of (SolrCloud).

roles

Future param for SolrCloud or a way for users to mark nodes for their own use.

Additional "user defined" properties may be specified for use as variables. For more information on how to define local properties, see the section Substituting Properties in Solr Config Files.

Format of solr.xml CoreAdmin API