Core discovery means that creating a core is as simple as a
core.properties file located on disk.
In Solr, the term core is used to refer to a single index and associated transaction log and configuration files (including the
solrconfig.xml and schema files, among others).
Your Solr installation can have multiple cores if needed, which allows you to index data with different structures in the same server, and maintain control over how your data is presented to different audiences.
In SolrCloud mode you will be more familiar with the term collection.
Behind the scenes a collection consists of one or more cores.
Cores can be created using
bin/solr script or as part of SolrCloud collection creation using the APIs.
Core-specific properties (such as the directories to use for the indexes or configuration files, the core name, and other options) are defined in a
core.properties file in any directory of your Solr installation (or in a directory under where
solr_home is defined) will be found by Solr and the defined properties will be used for the core named in the file.
core.properties file is a simple Java Properties file where each line is just a key=value pair, e.g.,
Notice that no quotes are required.
core.properties file looks like the example below.
However, it can also be empty, see information on placement of
Solr cores are configured by placing a file named
core.properties in a sub-directory under
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:
In this example, the enumeration will stop at "core1".
The following is legal:
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.
core.properties file can be empty if necessary.
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
The dataDir will be
You can run Solr without configuring any cores.
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.
The following properties are available:
The name of the SolrCore. You’ll use this name to reference the SolrCore when running commands with the
The configuration file name for a given core.
Default: see description
The schema file name for a given core. The default is
schema.xmlbut 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
managedSchemaResourceNamewill be read once, backed up, and converted for managed schema use. See Schema Factory Configuration for more details.
The core’s data directory (where indexes are stored) as either an absolute pathname, or a path relative to the value of
The name of a defined configset, if desired, to use to configure the core (see the section Configsets for more details).
The name of the properties file for this core. The value can be an absolute pathname or a path relative to the value of
true, the core can be unloaded if Solr reaches the
transientCacheSize. Cores are unloaded in order of least recently used first. Setting this to
trueis not recommended in SolrCloud mode.
true, the default, the core will loaded when Solr starts. Setting this to
falseis not recommended in SolrCloud mode.
Default: see description
Used only in SolrCloud, this is a unique identifier for the node hosting this replica. By default a
coreNodeNameis generated automatically, but setting this attribute explicitly allows you to manually assign a new core to replace an existing replica. For example, this can be useful when replacing a machine that has had a hardware failure by restoring from backups on a new machine with a new hostname or port.
The absolute or relative directory for the update log for this core (SolrCloud only).
The shard to assign this core to (SolrCloud only).
The name of the collection this core is part of (SolrCloud only).
Future parameter 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 Property Substitution in Configuration Files.