Managing Solr Using solrctl
Use the solrctl utility to manage a SolrCloud deployment. You can manipulate SolrCloud collections, SolrCloud collection instance directories, and individual cores.
A SolrCloud collection is the top-level object for indexing documents and providing a query interface. Each collection must be associated with an instance directory. Different collections can use the same instance directory. Each collection is typically replicated among several SolrCloud instances. Each replica is called a core and is assigned to an individual Solr service. The assignment process is managed automatically, although you can apply fine-grained control over each individual core using the solrctl core command. A typical deployment workflow with solrctl consists of:
- Deploying the ZooKeeper coordination service.
- Deploying solr-server daemons to each host.
- Initializing the state of the ZooKeeper coordination service using init command.
- Starting each solr-server daemon.
- Establishing a configuration.
- If using Configs, creating a config from a config template.
- If using instance directories, generating an instance directory and uploading the instance directory to ZooKeeper.
- Associating a new collection with the name of the config or instance directory.
Understanding configs and instancedirs
solrctl includes a config command that uses the Config API to directly manage configurations represented in Config objects. Config objects represent collection configuration information as specified by the solrctl collection --create -c configName command. instancedir and Config objects handle the same information, meeting the same need from the Solr server perspective, but there a number of differences between these two implementations.
| Attribute | Config | instancedir |
|---|---|---|
| Security | Security support provided.
|
|
| Creation method | Generated from existing config or instancedir in ZooKeeper using the ConfigSet API. | Manually edited locally and re-uploaded directly to ZooKeeper using solrctl utility. |
| Template support |
|
One standard template. |
| Sentry support | Configs include a number of templates, each with Sentry-enabled and non-Sentry-enabled versions. To enable Sentry, choose a Sentry-enabled template. | instancedirs include a single template that supports enabling Sentry. To enable Sentry with instancedirs, overwrite the original solrconfig.xml file with solrconfig.xml.secure as described in Enabling Solr as a Client for the Sentry Service Using the Command Line. |
Included Immutable Config Templates
Configs can be declared as immutable, which means they cannot be deleted or have their Schema updated by the Schema API. Immutable configs are uneditable config templates that are the basis for additional configs.
Solr provides a set of immutable config templates. These templates are only available after Solr initialization, so templates are not available in upgrades until after Solr is initialized or re-initialized. Templates include:
| Template Name | Supports Schema API | Uses Schemaless Solr | Supports Sentry |
|---|---|---|---|
| predefinedTemplate |  |
|
|
| managedTemplate |  |
|
|
| schemalessTemplate | |
|
|
| predefinedTemplateSecure | |
|
|
| managedTemplateSecure | |
|
|
| schemalessTemplateSecure | |
|
|