This is the documentation for Cloudera Enterprise 5.8.x. Documentation for other versions is available at Cloudera Documentation.

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.

Table 1. Config and instancedir Comparison
Attribute Config instancedir
Security Security support provided.
  • In a Kerberos-enabled cluster, the ZooKeeper hosts associated with configurations created using the Config API automatically has proper ZooKeeper ACLs. Because instancedir updates ZooKeeper directly, it is the client's responsibility to add the proper ACLs, which is cumbersome.
  • Sentry can be used to control access to the Config API, providing access control. For more information, see Configuring Sentry Authorization for Solr.
 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:

Table 2. Available Config Templates and Attributes
Template Name Supports Schema API Uses Schemaless Solr Supports Sentry
predefinedTemplate Feature Absent Feature Absent Feature Absent
managedTemplate Feature Present Feature Absent Feature Absent
schemalessTemplate Feature Present Feature Present Feature Absent
predefinedTemplateSecure Feature Absent Feature Absent Feature Present
managedTemplateSecure Feature Present Feature Absent Feature Present
schemalessTemplateSecure Feature Present Feature Present Feature Present
Page generated July 8, 2016.