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 SolrCloud collection must be associated with an instance directory. Although, different collections can use the same instance directory. Each SolrCloud collection is typically replicated (sharded) among several SolrCloud instances. Each replica is called a SolrCloud core and is assigned to an individual SolrCloud host. The assignment process is managed automatically, although you can apply fine-grained control over each individual core using the 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. instancedirs 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.
|
No ZooKeeper security support. Any user can create, delete, or modify instancedirs directly in ZooKeeper. |
| Creation method | Generated from existing configs or instancedirs in ZooKeeper using the ConfigSet API. | Manually edited locally and re-uploaded directly to ZooKeeper using solrctl instancedir. |
| Template support | Several predefined templates are available. These can be used as the basis for creating
additional configs. Additional templates can be created by creating configs that are immutable.
Mutable templates that use a Managed Schema can be modified using the Schema API as opposed to being manually edited. As a result, configs are less flexible, but they are also less error-prone than instancedirs. |
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 | |
|
|