Apache Solr Documentation

6.5 Ref Guide (PDF Download)
Solr Tutorial
Solr Community Wiki

Older Versions of this Guide (PDF)

6.6 Draft Ref Guide Topics


This Unreleased Guide Covers Apache Solr 6.6
As of 5 May 2017, committer editing of this Ref Guide is LOCKED for migration to the new Ref Guide. See SOLR-10290 for details.

Skip to end of metadata
Go to start of metadata

Solr's Administration page (found by default at  http://hostname:8983/solr/ ), provides a section with menu items for monitoring indexing and performance statistics, information about index distribution and replication, and information on all threads running in the JVM at the time. There is also a section where you can run queries, and an assistance area.

In addition, SolrCloud provides its own administration page (found at http://localhost:8983/solr/#/~cloud), as well as a few tools available via a ZooKeeper Command Line Utility (CLI). The CLI scripts found in server/scripts/cloud-scripts let you upload configuration information to ZooKeeper, in the same two ways that were shown in the examples in Parameter Reference. It also provides a few other commands that let you link collection sets to collections, make ZooKeeper paths or clear them, and download configurations from ZooKeeper to the local filesystem.


Solr's zkcli.sh vs ZooKeeper's zkCli.sh vs Solr Start Script

The zkcli.sh provided by Solr is not the same as the zkCli.sh included in ZooKeeper distributions

ZooKeeper's zkCli.sh provides a completely general, application-agnostic shell for manipulating data in ZooKeeper. Solr's zkcli.sh – discussed in this section – is specific to Solr, and has command line arguments specific to dealing with Solr data in ZooKeeper.

Many of the functions provided by the zkCli.sh script are also provided by the Solr Control Script Reference, which may be more familiar as the start script ZooKeeper maintenance commands are very similar to Unix commands.

Using Solr's ZooKeeper CLI

Both zkcli.sh (for Unix environments) and zkcli.bat (for Windows environments) support the following command line options:


Parameter Usage



-cmd <arg>

CLI Command to be executed: bootstrap, upconfig, downconfig, linkconfig, makepath, get, getfile, put, putfile, list, clear or clusterprop. This parameter is mandatory.


-zkhost <locations>

ZooKeeper host address. This parameter is mandatory for all CLI commands.


-collection <name>

For linkconfig: name of the collection.


-confdir <path>

For upconfig: a directory of configuration files. For downconfig: the destination of files pulled from ZooKeeper



Display help text.


-confname <arg>

For upconfig, linkconfig, downconfig: name of the configuration set.


-runzk <port>

Run ZooKeeper internally by passing the Solr run port; only for clusters on one machine.


-solrhome <path>

For bootstrap or when using -runzk: the mandatory solrhome location.

 -name <name>

For clusterprop: the mandatory cluster property name.

 -val <value>

For clusterprop: the cluster property value. If not specified, null will be used as value.

The short form parameter options may be specified with a single dash (eg: -c mycollection).

The long form parameter options may be specified using either a single dash (eg: -collection mycollection) or a double dash (eg: --collection mycollection)

ZooKeeper CLI Examples

Below are some examples of using the zkcli.sh CLI which assume you have already started the SolrCloud example (bin/solr -e cloud -noprompt)

If you are on Windows machine, simply replace zkcli.sh with zkcli.bat in these examples.

Upload a configuration directory

Bootstrap ZooKeeper from existing SOLR_HOME

Bootstrap with chroot

Using the boostrap command with a zookeeper chroot in the -zkhost parameter, e.g. -zkhost, will automatically create the chroot path before uploading the configs.

Put arbitrary data into a new ZooKeeper file

Put a local file into a new ZooKeeper file

Link a collection to a configuration set

Create a new ZooKeeper path

This can be useful to create a chroot path in ZooKeeper before first cluster start.

Set a cluster property

This command will add or modify a single cluster property in /clusterprops.json. Use this command instead of the usual getfile -> edit -> putfile cycle. Unlike the CLUSTERPROP REST API, this command does not require a running Solr cluster.



  • No labels


  1. A helpful page, thanks.

    But the table shows double hyphens for the long form of most options, whereas the examples show only a single one; the table has a single hyphen for collection.

    Also cmd isn't listed in the table (although it is mentioned in the paragraph before the table).

    1. thanks mark, i tried to clarify the table and added a comment about the fact that single and double dash opts are both valid.

  2. It would be good to mention not to use zookeeper/bin/zkCli.sh to upload solr config to zookeeper. both shell scripts have same name and it can confuse users. 

    1. great point Susmit.  I've added a Note box to the intro of the page to draw attention to this and clarifiy the differences betweeen the two.

      1. I think there is still a confusion In notes/warning section you says

        "ZooKeeper's zkCli.sh provides a completely general, application agnostic shell for manipulating data in ZooKeeper. Solr's zkcli.sh – discussed in on this page – is specific to Solr, and has command line arguments specific to dealing with Solr data in ZooKeeper."

        After said you put the Heading "Using The ZooKeeper CLI"above table. Now which one the table is about Solr's or the ZooKeeper  CLI?

        1. Adnan, another good point. I modified the heading to hopefully make it more clear.

  3. Command line utilities are now in example/scripts/cloud-scripts/ 

    not in example/cloud-scripts/

  4. If SolrCloud is hosted on HDFS, then how should the path of directories (solrHome on HDFS) be passed to the zkcli ? I think there should be some information regarding passing HDFS paths as arguments to the zkCli scripts.

    1. To my knowledge, data about HDFS and the solr home is not sent to zookeeper, it's managed with JVM startup parameters on solr itself, or possibly with JNDI variables.  If it's possible to have the info in solr.xml, then that can indirectly be in zookeeper ... but it would not be an argument on zkcli, it would be inside the solr.xml that gets uploaded to zookeeper, using the "putfile" command on zkcli.  I don't know whether it's possible to put HDFS options in solr.xml, though.


      Please use the mailing list or the IRC channel for getting help on Solr.  These comments are meant for discussion of the reference guide.  http://lucene.apache.org/solr/resources.html#community

  5. I follow the distinction on this page.   It would be an improvement to rename zkcli.sh to zksolrcli.sh to avoid confusion when both are in the path.   Even a power user is going to make this mistake.   This is very minor - but I guess the only way to get a change done is to submit a JIRA ticket.

  6. I second, what Daniel said. It would make a lot of sense to rename Solr's zkcli.sh so that it does not create extra confusion. zksolrcli.sh or solrzkcli.sh would be better.

  7. Should this page evolve into an overview of all the command-line utilities within Solr, as the title of this page implies?   

  8. Please add examples for how to use list and how to delete Solr configs in ZK.

    1. Listing configs can be done in the Solr Admin UI - click the Cloud tab, then click Tree, and the top level contents of the entire zookeeper tree will display.  Just open /configs and you will see all your configs in zookeeper.  The '-cmd list' functionality in our zkcli script will also show this to you, but it isn't quite as easy to read, because it also shows everything underneath each of the configs.

      I don't know of a way within the tools provided with Solr to delete a config.  It can be done using the 'rmr' command in the zkcli script included with zookeeper itself, which is different than the zkcli script included with Solr.  I think we probably need a "delconfig" command for our zkcli, which should check to be sure that the named config exists and is not being used by any of the existing collections.  I have filed SOLR-7124 to address this deficiency.

  9. Here is an example of manually removing nodes by modifying clusterstate.json  in ZK, which you may need to do if you delete some nodes and do not plan to recover them:

    1. Download clusterstate.json:

        zkcli.sh -z -cmd getfile /clusterstate.json clusterstateLoca.json

    2. Edit the downloaded closterstateLocal.json and save it

    3. Remove stale clusterstate.json from ZK: 

        zkcli.sh -z -cmd clear /clusterstate.json

    4. Upload modified clusterstate.json to ZK:

        zkcli.sh -z -cmd putfile /clusterstate.json ./clusterstateLocal.json

    1. Greg Solovyev This is NOT a recommended way of removing nodes. There are a more than a few things that could go wrong here. To begin with, there's no check for concurrency here i.e. you download, update and upload in 3 steps and clusterstate might have changed between these leading to loss of clusterstate info.

      Here's what is recommended:

      If you want to remove a node, taking it down by killing the running Solr instance would update the clusterstate.

      DELETEREPLICA Collections API call should be used to remove an existing replica.

  10. Well the upload and link config commands are alright but I am more interested in verification - whether these commands were successful.

    I can use the ls command to verify the config upload (-cmd upconfig) - but the Q is how do i know whether the link command has been successful in linking the config to a collection. Would really appreciate if someone throws some light on this. - Thanks