Apache Solr Ref Guide 5.1

User Manual:

Open the PDF directly: View PDF .
Page Count: 578

Download
Open PDF In Browser	View PDF

Apache Solr Reference Guide
Covering Apache Solr 5.1

Licensed to the Apache Software Foundation (ASF) under one
or more contributor license agreements. See the NOTICE file
distributed with this work for additional information
regarding copyright ownership. The ASF licenses this file
to you under the Apache License, Version 2.0 (the
"License"); you may not use this file except in compliance
with the License. You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing,
software distributed under the License is distributed on an
"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
KIND, either express or implied. See the License for the
specific language governing permissions and limitations
under the License.

Apache and the Apache feather logo are trademarks of The Apache Software Foundation. Apache Lucene, Apache
Solr and their respective logos are trademarks of the Apache Software Foundation. Please see the Apache
Trademark Policy for more information.
Fonts used in the Solr Reference Guide include Raleway, licensed under the SIL Open Font License, 1.1.

Apache Solr Reference Guide
This reference guide describes Apache Solr, the open source solution for search. You can download Apache
Solr from the Solr website at http://lucene.apache.org/solr/.
This Guide contains the following sections:
Getting Started: This section guides you through the installation and setup of Solr.
Using the Solr Administration User Interface: This section introduces the Solr Web-based user interface.
From your browser you can view configuration files, submit queries, view logfile settings and Java environment
settings, and monitor and control distributed configurations.
Documents, Fields, and Schema Design: This section describes how Solr organizes its data for indexing. It
explains how a Solr schema defines the fields and field types which Solr uses to organize data within the
document files it indexes.
Understanding Analyzers, Tokenizers, and Filters: This section explains how Solr prepares text for indexing
and searching. Analyzers parse text and produce a stream of tokens, lexical units used for indexing and
searching. Tokenizers break field data down into tokens. Filters perform other transformational or selective work
on token streams.
Indexing and Basic Data Operations: This section describes the indexing process and basic index operations,
such as commit, optimize, and rollback.
Searching: This section presents an overview of the search process in Solr. It describes the main components
used in searches, including request handlers, query parsers, and response writers. It lists the query parameters
that can be passed to Solr, and it describes features such as boosting and faceting, which can be used to
fine-tune search results.
The Well-Configured Solr Instance: This section discusses performance tuning for Solr. It begins with an
overview of the solrconfig.xml file, then tells you how to configure cores with solr.xml, how to configure
the Lucene index writer, and more.
Managing Solr: This section discusses important topics for running and monitoring Solr. Other topics include
how to back up a Solr instance, and how to run Solr with Java Management Extensions (JMX).
SolrCloud: This section describes the newest and most exciting of Solr's new features, SolrCloud, which
provides comprehensive distributed capabilities.
Legacy Scaling and Distribution: This section tells you how to grow a Solr distribution by dividing a large index
into sections called shards, which are then distributed across multiple servers, or by replicating a single index
across multiple services.
Client APIs: This section tells you how to access Solr through various client APIs, including JavaScript, JSON,
and Ruby.

Apache Solr Reference Guide 5.1

About This Guide
This guide describes all of the important features and functions of Apache Solr. It is free to download from http://l
ucene.apache.org/solr/.
Designed to provide high-level documentation, this guide is intended to be more encyclopedic and less of a
cookbook. It is structured to address a broad spectrum of needs, ranging from new developers getting started to
well-experienced developers extending their application or troubleshooting. It will be of use at any point in the
application life cycle, for whenever you need authoritative information about Solr.
The material as presented assumes that you are familiar with some basic search concepts and that you can read
XML. It does not assume that you are a Java programmer, although knowledge of Java is helpful when working
directly with Lucene or when developing custom extensions to a Lucene/Solr installation.

Special Inline Notes
Special notes are included throughout these pages.
Note Type
Information

Notes

Tip

Warning

Look & Description
Notes with a blue background are used for information that is important for you to
know.

Yellow notes are further clarifications of important points to keep in mind while using
Solr.

Notes with a green background are Helpful Tips.

Notes with a red background are warning messages.

Hosts and Port Examples
The default port when running Solr is 8983. The samples, URLs and screenshots in this guide may show
different ports, because the port number that Solr uses is configurable. If you have not customized your
installation of Solr, please make sure that you use port 8983 when following the examples, or configure your own
installation to use the port numbers shown in the examples. For information about configuring port numbers, see
Managing Solr.
Similarly, URL examples use 'localhost' throughout; if you are accessing Solr from a location remote to the server
hosting Solr, replace 'localhost' with the proper domain or IP where Solr is running.

Paths
Path information is given relative to solr.home, which is the location under the main Solr installation where
Solr's collections and their conf and data directories are stored. When running the various examples
mentioned through out this tutorial (i.e., bin/solr -e techproducts) the solr.home will be a sub directory
of example/ created for you automatically.

Apache Solr Reference Guide 5.1

Getting Started
Solr makes it easy for programmers to develop sophisticated, high-performance search applications with
advanced features such as faceting (arranging search results in columns with numerical counts of key terms).
Solr builds on another open source search technology: Lucene, a Java library that provides indexing and search
technology, as well as spellchecking, hit highlighting and advanced analysis/tokenization capabilities. Both Solr
and Lucene are managed by the Apache Software Foundation (www.apache.org).
The Lucene search library currently ranks among the top 15 open source projects and is one of the top 5 Apache
projects, with installations at over 4,000 companies. Lucene/Solr downloads have grown nearly ten times over
the past three years, with a current run-rate of over 6,000 downloads a day. The Solr search server, which
provides application builders a ready-to-use search platform on top of the Lucene search library, is the fastest
growing Lucene sub-project. Apache Lucene/Solr offers an attractive alternative to the proprietary licensed
search and discovery software vendors.
This section helps you get Solr up and running quickly, and introduces you to the basic Solr architecture and
features. It covers the following topics:
Installing Solr: A walkthrough of the Solr installation process.
Running Solr: An introduction to running Solr. Includes information on starting up the servers, adding documents,
and running queries.
A Quick Overview: A high-level overview of how Solr works.
A Step Closer: An introduction to Solr's home directory and configuration options.
Solr Start Script Reference: a complete reference of all of the commands and options available with the bin/solr
script.

Installing Solr
This section describes how to install Solr. You can install Solr in any system where a suitable Java Runtime
Environment (JRE) is available, as detailed below. Currently this includes Linux, OS X, and Microsoft Windows.
The instructions in this section should work for any platform, with a few exceptions for Windows as noted.

Got Java?
You will need the Java Runtime Environment (JRE) version 1.7 or higher. At a command line, check your Java
version like this:
$ java -version
java version "1.7.0_55"
Java(TM) SE Runtime Environment (build 1.7.0_55-b13)
Java HotSpot(TM) 64-Bit Server VM (build 24.55-b03, mixed mode)

The output will vary, but you need to make sure you have version 1.7 or higher. If you don't have the required
version, or if the java command is not found, download and install the latest version from Oracle at http://www.or
acle.com/technetwork/java/javase/downloads/index.html.

Installing Solr
Apache Solr Reference Guide 5.1

Solr is available from the Solr website at http://lucene.apache.org/solr/.
For Linux/Unix/OSX systems, download the .tgz file. For Microsoft Windows systems, download the .zip file.
When getting started, all you need to do is extract the Solr distribution archive to a directory of your choosing.
When you're ready to setup Solr for a production environment, please refer to the instructions provided on the Ta
king Solr to Production page. To keep things simple for now, extract the Solr distribution archive to your local
home directory, for instance on Linux, do:
$ cd ~/
$ tar zxf solr-5.0.0.tgz

Once extracted, you are now ready to run Solr using the instructions provided in the Running Solr section.

Running Solr
This section describes how to run Solr with an example schema, how to add documents, and how to run queries.

Start the Server
If you didn't start Solr after installing it, you can start it by running bin/solr from the Solr directory.
$ bin/solr start

If you are running Windows, you can start Solr by running bin\solr.cmd instead.
bin\solr.cmd start

This will start Solr in the background, listening on port 8983.
When you start Solr in the background, the script will wait to make sure Solr starts correctly before returning to
the command line prompt.
The bin/solr and bin\solr.cmd scripts allow you to customize how you start Solr. Let's work through a few
examples of using the bin/solr script (if you're running Solr on Windows, the bin\solr.cmd works the same
as what is shown in the examples below):

Solr Script Options
The bin/solr script has several options.

Script Help
To see how to use the bin/solr script, execute:
$ bin/solr -help

For specific usage instructions for the start command, do:

Apache Solr Reference Guide 5.1

$ bin/solr start -help

Start Solr in the Foreground
Since Solr is a server, it is more common to run it in the background, especially on Unix/Linux. However, to start
Solr in the foreground, simply do:
$ bin/solr start -f

If you are running windows, you can run:
bin\solr.cmd start -f

Start Solr with a Different Port
To change the port Solr listens on, you can use the -p parameter when starting, such as:
$ bin/solr start -p 8984

Stop Solr
When running Solr in the foreground (using -f), then you can stop it using Ctrl-c. However, when running in the
background, you should use the stop command, such as:
$ bin/solr stop -p 8983

The stop command requires you to specify the port Solr is listening on or you can use the -all parameter to
stop all running Solr instances.

Start Solr with a Specific Example Configuration
Solr also provides a number of useful examples to help you learn about key features. You can launch the
examples using the -e flag. For instance, to launch the "techproducts" example, you would do:
$ bin/solr -e techproducts

Currently, the available examples you can run are: techproducts, dih, schemaless, and cloud. See the section Ru
nning with Example Configurations for details on each example.
Getting Started with SolrCloud
Running the cloud example starts Solr in SolrCloud mode. For more information on starting Solr in
cloud mode, see the section Getting Started with SolrCloud.

Check if Solr is Running
If you're not sure if Solr is running locally, you can use the status command:

Apache Solr Reference Guide 5.1

$ bin/solr status

This will search for running Solr instances on your computer and then gather basic information about them, such
as the version and memory usage.
That's it! Solr is running. If you need convincing, use a Web browser to see the Admin Console.
http://localhost:8983/solr/

The Solr Admin interface.
If Solr is not running, your browser will complain that it cannot connect to the server. Check your port number
and try again.

Create a Core
If you did not start Solr with an example configuration, you would need to create a core in order to be able to
index and search. You can do so by running:
$ bin/solr create -c

This will create a core that uses a data-driven schema which tries to guess the correct field type when you add
documents to the index.
To see all available options for creating a new core, execute:
$ bin/solr create -help

Add Documents
Solr is built to find documents that match queries. Solr's schema provides an idea of how content is structured
(more on the schema later), but without documents there is nothing to find. Solr needs input before it can do
much.

Apache Solr Reference Guide 5.1

You may want to add a few sample documents before trying to index your own content. The Solr installation
comes with different types of example documents located under the sub-directories of the example/ directory of
your installation.
In the bin/ directory is the post script, a command line tool which can be used to index different types of
documents. Do not worry too much about the details for now. The Indexing and Basic Data Operations section
has all the details on indexing.
To see some information about the usage of bin/post, use the -help option.
bin/post can post various types of content to Solr, including files in Solr's native XML and JSON formats, CSV
files, a directory tree of rich documents, or even a simple short web crawl. See the examples at the end of
`bin/post -help` for various commands to easily get started posting your content into Solr.
Go ahead and add all the documents in some example XML files:
$ bin/post -c gettingstarted example/exampledocs/*.xml
SimplePostTool version 5.0.0
Posting files to [base] url http://localhost:8983/solr/gettingstarted/update...
Entering auto mode. File endings considered are
xml,json,csv,pdf,doc,docx,ppt,pptx,xls,xlsx,odt,odp,ods,ott,otp,ots,rtf,htm,html,txt
,log
POSTing file gb18030-example.xml (application/xml) to [base]
POSTing file hd.xml (application/xml) to [base]
POSTing file ipod_other.xml (application/xml) to [base]
POSTing file ipod_video.xml (application/xml) to [base]
POSTing file manufacturers.xml (application/xml) to [base]
POSTing file mem.xml (application/xml) to [base]
POSTing file money.xml (application/xml) to [base]
POSTing file monitor.xml (application/xml) to [base]
POSTing file monitor2.xml (application/xml) to [base]
POSTing file mp500.xml (application/xml) to [base]
POSTing file sd500.xml (application/xml) to [base]
POSTing file solr.xml (application/xml) to [base]
POSTing file utf8-example.xml (application/xml) to [base]
POSTing file vidcard.xml (application/xml) to [base]
14 files indexed.
COMMITting Solr index changes to http://localhost:8983/solr/gettingstarted/update...
Time spent: 0:00:00.153

That's it! Solr has indexed the documents contained in those files.

Ask Questions
Now that you have indexed documents, you can perform queries. The simplest way is by building a URL that
includes the query parameters. This is exactly the same as building any other HTTP URL.
For example, the following query searches all document fields for "video":
http://localhost:8983/solr/gettingstarted/select?q=video
Notice how the URL includes the host name (localhost), the port number where the server is listening (8983),
the application name (solr), the request handler for queries (select), and finally, the query itself (q=video).
The results are contained in an XML document, which you can examine directly by clicking on the link above.
The document contains two parts. The first part is the responseHeader, which contains information about the

Apache Solr Reference Guide 5.1

response itself. The main part of the reply is in the result tag, which contains one or more doc tags, each of
which contains fields from documents that match the query. You can use standard XML transformation
techniques to mold Solr's results into a form that is suitable for displaying to users. Alternatively, Solr can output
the results in JSON, PHP, Ruby and even user-defined formats.
Just in case you are not running Solr as you read, the following screen shot shows the result of a query (the next
example, actually) as viewed in Mozilla Firefox. The top-level response contains a lst named responseHeade
r and a result named response. Inside result, you can see the three docs that represent the search results.

An XML response to a query.
Once you have mastered the basic idea of a query, it is easy to add enhancements to explore the query syntax.
This one is the same as before but the results only contain the ID, name, and price for each returned document.
If you don't specify which fields you want, all of them are returned.
http://localhost:8983/solr/gettingstarted/select?q=video&fl=id,name,price
Here is another example which searches for "black" in the name field only. If you do not tell Solr which field to

Apache Solr Reference Guide 5.1

search, it will search default fields, as specified in the schema.
http://localhost:8983/solr/gettingstarted/select?q=name:black
You can provide ranges for fields. The following query finds every document whose price is between $0 and
$400.
http://localhost:8983/solr/gettingstarted/select?q=price:[0%20TO%20400]&fl=id,name
,price
Faceted browsing is one of Solr's key features. It allows users to narrow search results in ways that are
meaningful to your application. For example, a shopping site could provide facets to narrow search results by
manufacturer or price.
Faceting information is returned as a third part of Solr's query response. To get a taste of this power, take a look
at the following query. It adds facet=true and facet.field=cat.
http://localhost:8983/solr/gettingstarted/select?q=price:[0%20TO%20400]&fl=id,name
,price&facet=true&facet.field=cat
In addition to the familiar responseHeader and response from Solr, a facet_counts element is also present.
Here is a view with the responseHeader and response collapsed so you can see the faceting information
clearly.

Apache Solr Reference Guide 5.1

An XML Response with faceting

...

SOLR1000
Solr, the Enterprise Search Server
0.0
...

6
3
2
2
1
1
1
1
1
1
0
0
0
0
0

The facet information shows how many of the query results have each possible value of the cat field. You could
easily use this information to provide users with a quick way to narrow their query results. You can filter results
by adding one or more filter queries to the Solr request. Here is a request further constraining the request to
documents with a category of "software".
http://localhost:8983/solr/gettingstarted/select?q=price:0%20TO%20400&fl=id,name,p
rice&facet=true&facet.field=cat&fq=cat:software

A Quick Overview
Having had some fun with Solr, you will now learn about all the cool things it can do.
Here is a example of how Solr might be integrated into an application:

Apache Solr Reference Guide 5.1

In the scenario above, Solr runs along side other server applications. For example, an online store application
would provide a user interface, a shopping cart, and a way to make purchases for end users; while an inventory
management application would allow store employees to edit product information. The product metadata would
be kept in some kind of database, as well as in Solr.
Solr makes it easy to add the capability to search through the online store through the following steps:
1. Define a schema. The schema tells Solr about the contents of documents it will be indexing. In the online
store example, the schema would define fields for the product name, description, price, manufacturer, and
so on. Solr's schema is powerful and flexible and allows you to tailor Solr's behavior to your application.
See Documents, Fields, and Schema Design for all the details.
2. Deploy Solr to your application server.
3. Feed Solr the document for which your users will search.
4. Expose search functionality in your application.
Because Solr is based on open standards, it is highly extensible. Solr queries are RESTful, which means, in
essence, that a query is a simple HTTP request URL and the response is a structured document: mainly XML,
but it could also be JSON, CSV, or some other format. This means that a wide variety of clients will be able to
use Solr, from other web applications to browser clients, rich client applications, and mobile devices. Any
platform capable of HTTP can talk to Solr. See Client APIs for details on client APIs.
Solr is based on the Apache Lucene project, a high-performance, full-featured search engine. Solr offers support
for the simplest keyword searching through to complex queries on multiple fields and faceted search results. Sea
rching has more information about searching and queries.
If Solr's capabilities are not impressive enough, its ability to handle very high-volume applications should do the
trick.
A relatively common scenario is that you have so much data, or so many queries, that a single Solr server is
unable to handle your entire workload. In this case, you can scale up the capabilities of your application using So

Apache Solr Reference Guide 5.1

lrCloud to better distribute the data, and the processing of requests, across many servers. Multiple options can
be mixed and matched depending on the type of scalability you need.
For example: "Sharding" is a scaling technique in which a collection is split into multiple logical pieces called
"shards" in in order to scale up the number of documents in a collection beyond what could physically fit on a
single server. Incoming queries are distributed to every shard in the collection, which respond with merged
results. Another technique available is to increase the "Replication Factor" of your collection, which allows you to
add servers with additional copies of your collection to handle higher concurrent query load by spreading the
requests around to multiple machines. Sharding and Replication are not mutually exclusive, and together make
Solr an extremely powerful and scalable platform.
Best of all, this talk about high-volume applications is not just hypothetical: some of the famous Internet sites that
use Solr today are Macy's, EBay, and Zappo's.
For more information, take a look at https://wiki.apache.org/solr/PublicServers.

A Step Closer
You already have some idea of Solr's schema. This section describes Solr's home directory and other
configuration options.
When Solr runs in an application server, it needs access to a home directory. The home directory contains
important configuration information and is the place where Solr will store its index. The layout of the home
directory will look a little different when you are running Solr in standalone mode vs when you are running in
SolrCloud mode.
The crucial parts of the Solr home directory are shown in these examples:
Standalone Mode
/
solr.xml
core_name1/
core.properties
conf/
solrconfig.xml
schema.xml
data/
core_name2/
core.properties
conf/
solrconfig.xml
schema.xml
data/

Apache Solr Reference Guide 5.1

SolrCloud Mode
/
solr.xml
core_name1/
core.properties
data/
core_name2/
core.properties
data/

You may see other files, but the main ones you need to know are:
solr.xml specifies configuration options for your Solr server instance. For more information on solr.xm
l see Solr Cores and solr.xml.
Per Solr Core:
core.properties defines specific properties for each core such as its name, the collection the
core belongs to, the location of the schema, and other parameters. For more details on core.pro
perties, see the section Defining core.properties.
solrconfig.xml controls high-level behavior. You can, for example, specify an alternate location
for the data directory. For more information on solrconfig.xml, see Configuring solrconfig.xml.
schema.xml describes the documents you will ask Solr to index. Inside schema.xml, you define
a document as a collection of fields. You get to define both the field types and the fields
themselves. Field type definitions are powerful and include information about how Solr processes
incoming field values and query values. For more information on schema.xml, see Documents,
Fields, and Schema Design.
data/ The directory containing the low level index files.
Note that the SolrCloud example does not include a conf directory for each Solr Core (so there is no solrconf
ig.xml or schema.xml). This is because the configuration files usually found in the conf directory are stored
in ZooKeeper so they can be propagated across the cluster.
If you are using SolrCloud with the embedded ZooKeeper instance, you may also see zoo.cfg and zoo.data
which are ZooKeeper configuration and data files. However, if you are running your own ZooKeeper ensemble,
you would supply your own ZooKeeper configuration file when you start it and the copies in Solr would be
unused. For more information about ZooKeeper and SolrCloud, see the section SolrCloud.

Solr Start Script Reference
Solr includes a script known as "bin/solr" that allows you to start and stop Solr, create and delete collections
or cores, and check the status of Solr and configured shards. You can find the script in the bin/ directory of your
Solr installation. The bin/solr script makes Solr easier to work with by providing simple commands and
options to quickly accomplish common goals.
In this section, the headings below correspond to available commands. For each command, the available options
are described with examples.
More examples of bin/solr in use are available throughout the Solr Reference Guide, but particularly in the
sections Running Solr and Getting Started with SolrCloud.

Apache Solr Reference Guide 5.1

Starting and Stopping
Start and Restart
Status
Stop
Healthcheck
Collections and Cores
Create
Delete

Starting and Stopping
Start and Restart
The start command starts Solr. The restart command allows you to restart Solr while it is already running or if it
has been stopped already.
The start and restart commands have several options to allow you to run in SolrCloud mode, use an example
configuration set, start with a hostname or port that is not the default and point to a local ZooKeeper ensemble.
bin/solr start [options]
bin/solr start -help
bin/solr restart [options]
bin/solr restart -help
When using the restart command, you must pass all of the parameters you initially passed when you started
Solr. Behind the scenes, a stop request is initiated, so Solr will be stopped before being started again. If no
nodes are already running, restart will skip the step to stop and proceed to starting Solr.

Available Parameters
The bin/solr script provides many options to allow you to customize the server in common ways, such as
changing the listening port. However, most of the defaults are adequate for most Solr installations, especially
when just getting started.

Parameter

Description

Example

-a ""

Start Solr with additional JVM
parameters, such as those starting with
-X. If you are passing JVM parameters
that begin with "-D", you can omit the -a
option.

bin/solr start -a
"-Xdebug -Xrunjdwp:transport=dt_socket,
server=y,suspend=n,address=1044"

Apache Solr Reference Guide 5.1

-cloud

Start Solr in SolrCloud mode, which will
also launch the embedded ZooKeeper
instance included with Solr.

bin/solr start -c

This option can be shortened to simply
-c.
If you are already running a ZooKeeper
ensemble that you want to use instead
of the embedded (single-node)
ZooKeeper, you should also pass the -z
parameter.
For more details, see the section SolrCl
oud Mode below.
-d

Define a server directory, defaults to se

bin/solr start -d newServerDir

rver (as in, $SOLR_HOME/server). It
is uncommon to override this option.
When running multiple instances of Solr
on the same host, it is more common to
use the same server directory for each
instance and use a unique Solr home
directory using the -s option.
-e

Start Solr with an example
configuration. These examples are
provided to help you get started faster
with Solr generally, or just try a specific
feature.

bin/solr start -e schemaless

The available options are:
cloud
techproducts
dih
schemaless
See the section Running with Example
Configurations below for more details
on the example configurations.
-f

Start Solr in the foreground; you cannot
use this option when running examples
with the -e option.

bin/solr start -f

-h

Start Solr with the defined hostname. If
this is not specified, 'localhost' will be
assumed.

bin/solr start -h search.mysolr.com

Apache Solr Reference Guide 5.1

-m

Start Solr with the defined value as the
min (-Xms) and max (-Xmx) heap size
for the JVM.

bin/solr start -m 1g

-noprompt

Start Solr and suppress any prompts
that may be seen with another option.
This would have the side effect of
accepting all defaults implicitly.

bin/solr start -e cloud -noprompt

For example, when using the "cloud"
example, an interactive session guides
you through several options for your
SolrCloud cluster. If you want to accept
all of the defaults, you can simply add
the -noprompt option to your request.
-p

Start Solr on the defined port. If this is
not specified, '8983' will be used.

bin/solr start -p 8655

-s

Sets the solr.solr.home system
property; Solr will create core
directories under this directory. This
allows you to run multiple Solr
instances on the same host while
reusing the same server directory set
using the -d parameter. If set, the
specified directory should contain a
solr.xml file. The default value is serve

bin/solr start -s newHome

r/solr.
This parameter is ignored when running
examples (-e), as the solr.solr.home
depends on which example is run.
-V

Start Solr with verbose messages from
the start script.

bin/solr start -V

-z

Start Solr with the defined ZooKeeper
connection string. This option is only
used with the -c option, to start Solr in
SolrCloud mode. If this option is not
provided, Solr will start the embedded
ZooKeeper instance and use that
instance for SolrCloud operations.

bin/solr start -c -z
server1:2181,server2:2181

To emphasize how the default settings work take a moment to understand that the following commands are
equivalent:
bin/solr start
bin/solr start -h localhost -p 8983 -d server -s solr -m 512m

Apache Solr Reference Guide 5.1

It is not necessary to define all of the options when starting if the defaults are fine for your needs.

Setting Java System Properties
The bin/solr script will pass any additional parameters that begin with -D to the JVM, which allows you to set
arbitrary Java system properties. For example, to set the auto soft-commit frequency to 3 seconds, you can do:
bin/solr start -Dsolr.autoSoftCommit.maxTime=3000

SolrCloud Mode
The -c and -cloud options are equivalent:
bin/solr start -c
bin/solr start -cloud
If you specify a ZooKeeper connection string, such as -z 192.168.1.4:2181, then Solr will connect to
ZooKeeper and join the cluster. If you do not specify the -z option when starting Solr in cloud mode, then Solr will
launch an embedded ZooKeeper server listening on the Solr port + 1000, i.e., if Solr is running on port 8983,
then the embedded ZooKeeper will be listening on port 9983.
IMPORTANT: If your ZooKeeper connection string uses a chroot, such as localhost:2181/solr, then you
need to bootstrap the /solr znode before launching SolrCloud using the bin/solr script. To do this, you need to
use the zkcli.sh script shipped with Solr, such as:
server/scripts/cloud-scripts/zkcli.sh -zkhost localhost:2181/solr -cmd bootstrap
-solrhome server/solr
When starting in SolrCloud mode, the interactive script session will prompt you to choose a configset to use.
For more information about starting Solr in SolrCloud mode, see also the section Getting Started with SolrCloud.

Running with Example Configurations
bin/solr start -e
The example configurations allow you to get started quickly with a configuration that mirrors what you hope to
accomplish with Solr. The following examples are provided:
cloud: This example starts a 1-4 node SolrCloud cluster on a single machine. When chosen, an
interactive session will start to guide you through options to select the number of nodes for your example
cluster, the ports to use, and name of the collection to be created.
techproducts: This example starts Solr in standalone mode with a schema designed for the sample
documents included in the $SOLR_HOME/example/exampledocs directory. The configset used does
not have SolrCloud or schemaless modes enabled, so fields must be explicitly defined in schema.xmlin
order for documents including those fields to be added to the index. The configset used can be found in $
SOLR_HOME/server/solr/configsets/sample_techproducts_configs.
dih: This example starts Solr in standalone mode with the DataImportHandler (DIH) enabled and several
example dataconfig.xml files pre-configured for different types of data supported with DIH (such as,
database contents, email, RSS feeds, etc.). For more information about DIH, see the section Uploading
Structured Data Store Data with the Data Import Handler.
schemaless: This example starts Solr in standalone mode using a managed schema, as described in the
section Managed Schema Definition in SolrConfig, and provides a very minimal pre-defined schema. Solr

Apache Solr Reference Guide 5.1

will run in Schemaless Mode with this configuration, where Solr will create fields in the schema on the fly
and will guess field types used in incoming documents. The configset used can be found in $SOLR_HOME
/server/solr/configsets/data_driven_schema_configs.
Note: The run-in-foreground option (-f) does not work with the -e option since the script needs to perform
additional tasks after starting the Solr server.

Status
The status command displays basic JSON-formatted information for any Solr nodes found running on the local
system. The status command uses the SOLR_PID_DIR environment variable to locate Solr process ID files to
find running Solr instances; the SOLR_PID_DIR variable defaults to the bin directory.
bin/solr status
The output will include a status of each node of the cluster, as in this example:
Found 2 Solr nodes:
Solr process 39920 running on port 7574
{
"solr_home":"/Applications/Solr/solr-5.0.0/example/cloud/node2/solr/",
"version":"5.0.0 1658469 - anshumgupta - 2015-02-09 09:54:36",
"startTime":"2015-02-10T17:19:54.739Z",
"uptime":"1 days, 23 hours, 55 minutes, 48 seconds",
"memory":"77.2 MB (%15.7) of 490.7 MB",
"cloud":{
"ZooKeeper":"localhost:9865",
"liveNodes":"2",
"collections":"2"}}
Solr process 39827 running on port 8865
{
"solr_home":"/Applications/Solr/solr-5.0.0/example/cloud/node1/solr/",
"version":"5.0.0 1658469 - anshumgupta - 2015-02-09 09:54:36",
"startTime":"2015-02-10T17:19:49.057Z",
"uptime":"1 days, 23 hours, 55 minutes, 54 seconds",
"memory":"94.2 MB (%19.2) of 490.7 MB",
"cloud":{
"ZooKeeper":"localhost:9865",
"liveNodes":"2",
"collections":"2"}}

Stop
The stop command sends a STOP request to a running Solr node, which allows it to shutdown gracefully. The
command will wait up to 5 seconds for Solr to stop gracefully and then will forcefully kill the process (kill -9).
bin/solr stop [options]
bin/solr stop -help

Available Parameters
Parameter

Apache Solr Reference Guide 5.1

Description

Example

-p

Stop Solr running on the given port. If you are running more than one instance,
or are running in SolrCloud mode, you either need to specify the ports in
separate requests or use the -all option.

bin/solr
stop -p
8983

-all

Stop all running Solr instances that have a valid PID.

bin/solr
stop -all

-k

Stop key used to protect from stopping Solr inadvertently; default is "solrrocks".

bin/solr
stop -k
solrrocks

Healthcheck
The healthcheck command generates a JSON-formatted health report for a collection when running in SolrCloud
mode. The health report provides information about the state of every replica for all shards in a collection,
including the number of committed documents and its current state.
bin/solr healthcheck [options]
bin/solr healthcheck -help

Available Parameters
Parameter

Description

Example

-c

Name of the collection to run a healthcheck against (required).

bin/solr
healthcheck
-c
gettingstarted

-z

ZooKeeper connection string, defaults to localhost:9983. If you are
running Solr on a port other than 8983, you will have to specify the
ZooKeeper connection string. By default, this will be the Solr port + 1000.

bin/solr
healthcheck
-z
localhost:2181

Below is an example healthcheck request and response using a non-standard ZooKeeper connect string, with 2
nodes running:

Apache Solr Reference Guide 5.1

$ bin/solr healthcheck -c gettingstarted -z localhost:9865
{
"collection":"gettingstarted",
"status":"healthy",
"numDocs":0,
"numShards":2,
"shards":[
{
"shard":"shard1",
"status":"healthy",
"replicas":[
{
"name":"core_node1",
"url":"http://10.0.1.10:8865/solr/gettingstarted_shard1_replica2/",
"numDocs":0,
"status":"active",
"uptime":"2 days, 1 hours, 18 minutes, 48 seconds",
"memory":"25.6 MB (%5.2) of 490.7 MB",
"leader":true},
{
"name":"core_node4",
"url":"http://10.0.1.10:7574/solr/gettingstarted_shard1_replica1/",
"numDocs":0,
"status":"active",
"uptime":"2 days, 1 hours, 18 minutes, 42 seconds",
"memory":"95.3 MB (%19.4) of 490.7 MB"}]},
{
"shard":"shard2",
"status":"healthy",
"replicas":[
{
"name":"core_node2",
"url":"http://10.0.1.10:8865/solr/gettingstarted_shard2_replica2/",
"numDocs":0,
"status":"active",
"uptime":"2 days, 1 hours, 18 minutes, 48 seconds",
"memory":"25.8 MB (%5.3) of 490.7 MB"},
{
"name":"core_node3",
"url":"http://10.0.1.10:7574/solr/gettingstarted_shard2_replica1/",
"numDocs":0,
"status":"active",
"uptime":"2 days, 1 hours, 18 minutes, 42 seconds",
"memory":"95.4 MB (%19.4) of 490.7 MB",
"leader":true}]}]}

Collections and Cores
The bin/solr script can also help you create new collections (in SolrCloud mode) or cores (in standalone mode),
or delete collections.

Create
The create command detects the mode that Solr is running in (standalone or SolrCloud) and then creates a core
or collection depending on the mode.

Apache Solr Reference Guide 5.1

bin/solr create options
bin/solr create -help

Available Parameters
Parameter

Description

Example

-c

Name of the core or collection to create (required).

bin/solr
create -c
mycollection

-d

The configuration directory. This defaults to data_driven_schema_

bin/solr
create -d
basic_configs

configs.
See the section Configuration Directories and SolrCloud below for
more details about this option when running in SolrCloud mode.
-n

The configuration name. This defaults to the same name as the core
or collection.

bin/solr
create -n
basic

-p

Port of a local Solr instance to send the create command to; by
default the script tries to detect the port by looking for running Solr
instances.

bin/solr
create -p
8983

This option is useful if you are running multiple standalone Solr
instances on the same host, thus requiring you to be specific about
which instance to create the core in.
-s
-shards
-rf
-replicationFactor

Number of shards to split a collection into, default is 1; only applies
when Solr is running in SolrCloud mode.

bin/solr
create -s 2

Number of copies of each document in the collection. The default is 1
(no replication).

bin/solr -rf
2

Configuration Directories and SolrCloud
Before creating a collection in SolrCloud, the configuration directory used by the collection must be uploaded to
ZooKeeper. The create command supports several use cases for how collections and configuration directories
work. The main decision you need to make is whether a configuration directory in ZooKeeper should be shared
across multiple collections. Let's work through a few examples to illustrate how configuration directories work in
SolrCloud.
First, if you don't provide the -d or -n options, then the default configuration ($SOLR_HOME/server/solr/con
figsets/data_driven_schema_configs/conf) is uploaded to ZooKeeper using the same name as the
collection. For example, the following command will result in the data_driven_schema_configs configuration
being uploaded to /configs/contacts in ZooKeeper: bin/solr create -c contacts. If you create
another collection, by doing bin/solr create -c contacts2, then another copy of the data_driven_sch

Apache Solr Reference Guide 5.1

ema_configs directory will be uploaded to ZooKeeper under /configs/contacts2. Any changes you make
to the configuration for the contacts collection will not affect the contacts2 collection. Put simply, the default
behavior creates a unique copy of the configuration directory for each collection you create.
You can override the name given to the configuration directory in ZooKeeper by using the -n option. For
instance, the command bin/solr create -c logs -d basic_configs -n basic will upload the serve
r/solr/configsets/basic_configs/conf directory to ZooKeeper as /configs/basic.
Notice that we used the -d option to specify a different configuration than the default. Solr provides several
built-in configurations under server/solr/configsets. However you can also provide the path to your own
configuration directory using the -d option. For instance, the command bin/solr create -c mycoll -d
/tmp/myconfigs, will upload /tmp/myconfigs into ZooKeeper under /configs/mycoll . To reiterate, the
configuration directory is named after the collection unless you override it using the -n option.
Other collections can share the same configuration by specifying the name of the shared configuration using the
-n option. For instance, the following command will create a new collection that shares the basic configuration
created previously: bin/solr create -c logs2 -n basic.

Data-driven schema and shared configurations
The data_driven_schema_configs schema can mutate as data is indexed. Consequently, we recommend that
you do not share data-driven configurations between collections unless you are certain that all collections should
inherit the changes made when indexing data into one of the collections.

Delete
The delete command detects the mode that Solr is running in (standalone or SolrCloud) and then deletes the
specified core (standalone) or collection (SolrCloud) as appropriate.
bin/solr delete [options]
bin/solr delete -help
If running in SolrCloud mode, the delete command checks if the configuration directory used by the collection
you are deleting is being used by other collections. If not, then the configuration directory is also deleted from
ZooKeeper. For example, if you created a collection by doing bin/solr create -c contacts, then the
delete command bin/solr delete -c contacts will check to see if the /configs/contacts configuratio
n directory is being used by any other collections. If not, then the /configs/contacts directory is removed
from ZooKeeper.

Available Parameters
Parameter

Description

Example

-c

Name of the core / collection to delete (required).

bin/solr
delete -c
mycoll

-deleteConfig

Delete the configuration directory from ZooKeeper. The default is true.

bin/solr
delete
-deleteConfig
false

If the configuration directory is being used by another collection, then it
will not be deleted even if you pass -deleteConfig true.

Apache Solr Reference Guide 5.1

-p

The port of a local Solr instance to send the delete command to. By
default the script tries to detect the port by looking for running Solr
instances.

bin/solr
delete -p 8983

This option is useful if you are running multiple standalone Solr
instances on the same host, thus requiring you to be specific about
which instance to delete the core from.

Apache Solr Reference Guide 5.1

Upgrading Solr
If you are already using Solr 5.0, Solr 5.1 should not present any major problems. However, you should review
the CHANGES.txt file found in your Solr package for changes and updates that may effect your existing
implementation.

Upgrading from 5.0.x
SolrClient query functions now declare themselves as throwing IOException in addition to SolrSer
verException, to bring them in line with the update functions.
SolrRequest.process() is now final. Subclasses should instead be parameterized by their
corresponding SolrResponse type, and implement createResponse().
The signature of SolrDispatchFilter.createCoreContainer() has changed to take (String,P
roperties) arguments.
Deprecated the 'lib' option added to create-requesthandler as part of SOLR-6801 in 5.0 release.
Please use the add-runtimelib command.
Tika's runtime dependency of 'jhighlight' was removed as the latter was found to contain some LGPL-only
code. Until that's resolved by Tika, you can download the jar yourself and place it under contrib/extra
ction/lib.
The _text catch-all field in data_driven_schema_configs has been renamed to _text_.

Upgrading from Older Versions of Solr
Users upgrading from older versions are strongly encouraged to consult CHANGES.txt for the details of all cha
nges since the version they are upgrading from
For users upgrading from Solr 4.x, a summary of the significant changes can be found in the Major Changes
from Solr 4 to Solr 5 section.

Apache Solr Reference Guide 5.1

Using the Solr Administration User Interface
This section discusses the Solr Administration User Interface ("Admin UI").
The Overview of the Solr Admin UI explains the basic features of the user interface, what's on the initial Admin UI
page, and how to configure the interface. In addition, there are pages describing each screen of the Admin UI:
Getting Assistance shows you how to get more information about the UI.
Logging explains the various logging levels available and how to invoke them.
Cloud Screens display information about nodes when running in SolrCloud mode.
Core Admin explains how to get management information about each core.
Java Properties shows the Java information about each core.
Thread Dump lets you see detailed information about each thread, along with state information.
Core-Specific Tools is a section explaining additional screens available for each named core.
Analysis - lets you analyze the data found in specific fields.
Dataimport - shows you information about the current status of the Data Import Handler.
Documents - provides a simple form allowing you to execute various Solr indexing commands
directly from the browser.
Files - shows the current core configuration files such as solrconfig.xml and schema.xml.
Ping - lets you ping a named core and determine whether the core is active.
Plugins/Stats - shows statistics for plugins and other installed components.
Query - lets you submit a structured query about various elements of a core.
Replication - shows you the current replication status for the core, and lets you enable/disable
replication.
Schema Browser - displays schema data in a browser window.
Segments Info - Provides a visualization of the underlying Lucene index segments.

Overview of the Solr Admin UI
Solr features a Web interface that makes it easy for Solr administrators and programmers to view Solr
configuration details, run queries and analyze document fields in order to fine-tune a Solr configuration and
access online documentation and other help.

Apache Solr Reference Guide 5.1

Accessing the URL http://hostname:8983/solr/ will show the main dashboard, which is divided into two
parts.
A left-side of the screen is a menu under the Solr logo that provides the navigation through the screens of the UI.
The first set of links are for system-level information and configuration and provide access to Logging, Core
Admin and Java Properties, among other things. At the end of this information is a list of Solr cores configured
for this instance. Clicking on a core name shows a secondary menu of information and configuration options for
the core specifically. Items in this list include the Schema, Config, Plugins, and an ability to perform Queries on
indexed data.
The center of the screen shows the detail of the option selected. This may include a sub-navigation for the option
or text or graphical representation of the requested data. See the sections in this guide for each screen for more
details.
Under the covers, the Solr Admin UI re-uses the same HTTP APIs available to all clients to access Solr-related
data to drive an external interface.
The path to the Solr Admin UI given above is http://hostname:port/solr, which redirects to http
://hostname:port/solr/#/ in the current version. A convenience redirect is also supported, so
simply accessing the Admin UI at http://hostname:port/ will also redirect to http://hostname:
port/solr/#/.

Configuring the Admin UI in solrconfig.xml
You can configure the Solr Admin UI by editing the file solrconfig.xml.
The block in the solrconfig.xml file determines the default query to be displayed in the Query
section of the core-specific pages. The default is *:*, which is to find all documents. In this example, we have
changed the default to the term solr.

solr

Related Topics
Configuring solrconfig.xml

Getting Assistance
At the bottom of each screen of the Admin UI is a set of links that can be used to get more assistance with
configuring and using Solr.

Assistance icons
These icons include the following links.

Apache Solr Reference Guide 5.1

Link

Description

Documentation

Navigates to the Apache Solr documentation hosted on http://lucene.apache.org/solr/.

Issue Tracker

Navigates to the JIRA issue tracking server for the Apache Solr project. This server resides
at http://issues.apache.org/jira/browse/SOLR.

IRC Channel

Navigates to an Apache Wiki page describing how to join Solr's IRClive-chat room: https://wi
ki.apache.org/solr/IRCChannels.

Community
forum

Navigates to the Apache Solr web page http://lucene.apache.org/solr/resources.html#comm
unity which has further information about ways to engage.

Solr Query
Syntax

Navigates to the section "Query Syntax and Parsing" in this reference guide.

These links cannot be modified without editing the admin.html in the solr.war that contains the Admin UI
files.

Logging
The Logging page shows messages from Solr's log files.
When you click the link for "Logging", a page similar to the one below will be displayed:

The Main Logging Screen, including an example of an error due to a bad document sent by a client
While this example shows logged messages for only one core, if you have multiple cores in a single instance,
they will each be listed, with the level for each.

Selecting a Logging Level

Apache Solr Reference Guide 5.1

When you select the Level link on the left, you see the hierarchy of classpaths and classnames for your
instance. A row highlighted in yellow indicates that the class has logging capabilities. Click on a highlighted row,
and a menu will appear to allow you to change the log level for that class. Characters in boldface indicate that
the class will not be affected by level changes to root.
For an explanation of the various logging levels, see Configuring Logging.

Cloud Screens
When running in SolrCloud mode, an option will appear in the Admin UI between Logging and Core Admin for
Cloud. It's not possible at the current time to manage the nodes of the SolrCloud cluster from the Admin UI, but
you can view them and open the Solr Admin UI on each node to view the status and statistics for the node and
each core on each node.
Only Visible When using SolrCloud
The "Cloud" menu option is only available on Solr instances running in SolrCloud mode. Single node or
master/slave replication instances of Solr will not display this option.

Click on the Cloud option in the left-hand navigation, and a small sub-menu appears with options called "Tree",
"Graph", "Graph (Radial)" and "Dump". The default view ("Graph") shows a graph of each collection, the shards
that make up those collections, and the addresses of each replica for each shard. This example shows the very
simple two-node, two-shard, two-replica cluster you can get running the "bin/solr -e cloud" example:

Apache Solr Reference Guide 5.1

The "Graph (Radial)" option provides a different visual view of each node. Using the same example cluster, the
radial graph view looks like:

The "Tree" option shows a directory structure of the files in ZooKeeper, including clusterstate.json,
configuration files, and other status and information files. In this example, we show the leader definition for
"shard1" in the "gettingstarted" collection:

Apache Solr Reference Guide 5.1

The final option is "Dump", which allows you to download an XML file with all the ZooKeeper configuration files.

Core Admin
The Core Admin screen lets you manage your cores.
The buttons at the top of the screen let you add a new core, unload the core displayed, rename the currently
displayed core, swap the existing core with one that you specify in a drop-down box, reload the current core, and
optimize the current core.
The main display and available actions correspond to the commands used with the CoreAdminHandler, but
provide another way of working with your cores.

Java Properties
The Java Properties screen provides easy access to one of the most essential components of a top-performing
Solr systems With the Java Properties screen, you can see all the properties of the JVM running Solr, including
the class paths, file encodings, JVM memory settings, operating system, and more.

Apache Solr Reference Guide 5.1

Thread Dump
The Thread Dump screen lets you inspect the currently active threads on your server. Each thread is listed and
access to the stacktraces is available where applicable. Icons to the left indicate the state of the thread: for
example, threads with a green check-mark in a green circle are in a "RUNNABLE" state. On the right of the
thread name, a down-arrow means you can expand to see the stacktrace for that thread.

When you move your cursor over a thread name, a box floats over the name with the state for that thread.
Thread states can be:
State

Meaning

NEW

A thread that has not yet started.

RUNNABLE

A thread executing in the Java virtual machine.

BLOCKED

A thread that is blocked waiting for a monitor lock.

Apache Solr Reference Guide 5.1

WAITING

A thread that is waiting indefinitely for another thread to perform a particular action.

TIMED_WAITING

A thread that is waiting for another thread to perform an action for up to a specified
waiting time.

TERMINATED

A thread that has exited.

When you click on one of the threads that can be expanded, you'll see the stacktrace, as in the example below:

Inspecting a thread
You can also check the Show all Stacktraces button to automatically enable expansion for all threads.

Core-Specific Tools
In the left-hand navigation bar, you will see a pull-down menu titled "Core Selector". Clicking on the menu will
show a list of Solr cores, with a search box that can be used to find a specific core (handy if you have a lot of
cores). When you select a core, a secondary menu opens under the core name with the administration options
available for that particular core.

After selecting the core, the central part of the screen shows Statistics and other information about the core you

Apache Solr Reference Guide 5.1

chose. You can define a file called admin-extra.html that includes links or other information you would like to
display in the "Admin Extra" part of this main screen.
On the left side, under the core name, are links to other screens that display information or provide options for
the specific core chosen. The core-specific options are listed below, with a link to the section of this Guide to find
out more:
Analysis - lets you analyze the data found in specific fields.
Dataimport - shows you information about the current status of the Data Import Handler.
Documents - provides a simple form allowing you to execute various Solr indexing commands directly
from the browser.
Files - shows the current core configuration files such as solrconfig.xml and schema.xml.
Ping - lets you ping a named core and determine whether the core is active.
Plugins/Stats - shows statistics for plugins and other installed components.
Query - lets you submit a structured query about various elements of a core.
Replication - shows you the current replication status for the core, and lets you enable/disable replication.
Schema Browser - displays schema data in a browser window.
Segments Info - Provides a visualization of the underlying Lucene index segments.

Analysis Screen
The Analysis screen lets you inspect how data will be handled according to the field, field type and dynamic rule
configurations found in schema.xml. You can analyze how content would be handled during indexing or during
query processing and view the results separately or at the same time. Ideally, you would want content to be
handled consistently, and this screen allows you to validate the settings in the field type or field analysis chains.
Enter content in one or both boxes at the top of the screen, and then choose the field or field type definitions to
use for analysis.

If you click the Verbose Output check box, you see more information, including transformations to the input
(such as, convert to lower case, strip extra characters, etc.) and the bytes, type and detailed position information.
The information displayed will vary depending on the settings of the field or field type. Each step of the process is
displayed in a separate section, with an abbreviation for the tokenizer or filter that is applied in that step. Hover or
click on the abbreviation, and you'll see the name and path of the tokenizer or filter.

Apache Solr Reference Guide 5.1

In example screenshot above, several transformations are applied to the input "Running is a sport." The words
"is" and "a" have been removed and the word "running" has been changed to its basic form, "run". This is
because we are using the field type text_en in this scenario, which is configured to remove stop words (small
words that usually do not provide a great deal of context) and "stem" terms when possible to find more possible
matches (this is particularly helpful with plural forms of words). If you click the question mark next to the Analyze
Fieldname/Field Type pull-down menu, the Schema Browser window will open, showing you the settings for the
field specified.
The section Understanding Analyzers, Tokenizers, and Filters describes in detail what each option is and how it
may transform your data and the section Running Your Analyzer has specific examples for using the Analysis
screen.

Dataimport Screen
The Dataimport screen shows the configuration of the DataImportHandler (DIH) and allows you start, and
monitor the status of, import commands as defined by the options selected on the screen and defined in the
configuration file.

Apache Solr Reference Guide 5.1

This screen also lets you adjust various options to control how the data is imported to Solr, and view the data
import configuration file that controls the import. For more information about data importing with DIH, see the
section on Uploading Structured Data Store Data with the Data Import Handler.

Documents Screen
The Documents screen provides a simple form allowing you to execute various Solr indexing commands in a
variety of formats directly from the browser.

The screen allows you to:
Copy documents in JSON, CSV or XML and submit them to the index
Upload documents (in JSON, CSV or XML)
Construct documents by selecting fields and field values
The first step is to define the RequestHandler to use (aka, 'qt'). By default /update will be defined. To use Solr
Cell, for example, change the request handler to /update/extract.

Apache Solr Reference Guide 5.1

Then choose the Document Type to define the type of document to load. The remaining parameters will change
depending on the document type selected.

JSON
When using the JSON document type, the functionality is similar to using a requestHandler on the command line.
Instead of putting the documents in a curl command, they can instead be input into the Document entry box. The
document structure should still be in proper JSON format.
Then you can choose when documents should be added to the index (Commit Within), whether existing
documents should be overwritten with incoming documents with the same id (if this is not true, then the incoming
documents will be dropped), and, finally, if a document boost should be applied.
This option will only add or overwrite documents to the index; for other update tasks, see the Solr Command opti
on.

CSV
When using the CSV document type, the functionality is similar to using a requestHandler on the command line.
Instead of putting the documents in a curl command, they can instead be input into the Document entry box. The
document structure should still be in proper CSV format, with columns delimited and one row per document.
Then you can choose when documents should be added to the index (Commit Within), and whether existing
documents should be overwritten with incoming documents with the same id (if this is not true, then the incoming
documents will be dropped).

Document Builder
The Document Builder provides a wizard-like interface to enter fields of a document

File Upload
The File Upload option allows choosing a prepared file and uploading it. If using only /update for the
Request-Handler option, you will be limited to XML, CSV, and JSON.
However, to use the ExtractingRequestHandler (aka Solr Cell), you can modify the Request-Handler to /update
/extract. You must have this defined in your solrconfig.xml file, with your desired defaults. You should
also update the &literal.id shown in the Extracting Req. Handler Params so the file chosen is given a
unique id.
Then you can choose when documents should be added to the index (Commit Within), and whether existing
documents should be overwritten with incoming documents with the same id (if this is not true, then the incoming
documents will be dropped).

Solr Command
The Solr Command option allows you use XML or JSON to perform specific actions on documents, such as
defining documents to be added or deleted, updating only certain fields of documents, or commit and optimize
commands on the index.
The documents should be structured as they would be if using /update on the command line.

XML

Apache Solr Reference Guide 5.1

When using the XML document type, the functionality is similar to using a requestHandler on the command line.
Instead of putting the documents in a curl command, they can instead be input into the Document entry box. The
document structure should still be in proper Solr XML format, with each document separated by tags and
each field defined.
Then you can choose when documents should be added to the index (Commit Within), and whether existing
documents should be overwritten with incoming documents with the same id (if this is not true, then the incoming
documents will be dropped).
This option will only add or overwrite documents to the index; for other update tasks, see the Solr Command opti
on.

Related Topics
Uploading Data with Index Handlers
Uploading Data with Solr Cell using Apache Tika

Files Screen
The Files screen lets you browse & view the various configuration files (such solrconfig.xml and schema.x
ml) for the core you selected.

While the solrconfig.xml defines the behaviour of Solr as it indexes content and responds to queries, the sc
hema.xml allows you to define the types of data in your content (field types), the fields your documents will be
broken into, and any dynamic fields that should be generated based on patterns of field names in the incoming
documents. Any other configuration files are used depending on how they are referenced in either solrconfig
.xml or schema.xml.
Configuration files cannot be edited with this screen, so a text editor of some kind must be used.
This screen is related to the Schema Browser Screen, in that they both can display information from the schema,
but the Schema Browser provides a way to drill into the analysis chain and displays linkages between field types,

Apache Solr Reference Guide 5.1

fields, and dynamic field rules.
Many of the options defined in solrconfig.xml and schema.xml are described throughout the rest of this
Guide. In particular, you will want to review these sections:
Indexing and Basic Data Operations
Searching
The Well-Configured Solr Instance
Documents, Fields, and Schema Design

Ping
Choosing Ping under a core name issues a ping request to check whether a server is up.
Ping is configured using a requestHandler in the solrconfig.xml file:

solrpingquery

all

The Ping option doesn't open a page, but the status of the request can be seen on the core overview page
shown when clicking on a collection name. The length of time the request has taken is displayed next to the Ping
option, in milliseconds.

Plugins & Stats Screen
The Plugins screen shows information and statistics about Solr's status and performance. You can find
information about the performance of Solr's caches, the state of Solr's searchers, and the configuration of
searchHandlers and requestHandlers.
Choose an area of interest on the right, and then drill down into more specifics by clicking on one of the names
that appear in the central part of the window. In this example, we've chosen to look at the Searcher stats, from
the Core area:

Apache Solr Reference Guide 5.1

Searcher Statistics
The display is a snapshot taken when the page is loaded. You can get updated status by choosing to either Wat
ch Changes or Refresh Values. Watching the changes will highlight those areas that have changed, while
refreshing the values will reload the page with updated information.

Query Screen
You can use Query, shown under the name of each core, to submit a search query to a Solr server and analyze
the results. In the example in the screenshot, a query has been submitted, and the screen shows the query
results sent to the browser as JSON.

The query was sent to a core named "techproducts". We used Solr's default query for this screen (as defined in s

Apache Solr Reference Guide 5.1

olrconfig.xml), which is *:*. This query will find all records in the index for this core. We kept the other
defaults, but the table below explains these options, which are also covered in detail in later parts of this Guide.
The response is shown to the right of the form. Requests to Solr are simply HTTP requests, and the query
submitted is shown in light type above the results; if you click on this it will open a new browser window with just
this request and response (without the rest of the Solr Admin UI). The rest of the response is shown in JSON,
which is part of the request (see the wt=json part at the end).
The response has at least two sections, but may have several more depending on the options chosen. The two
sections it always has are the responseHeader and the response. The responseHeader includes the status
of the search (status), the processing time (QTime), and the parameters (params) that were used to process
the query.
The response includes the documents that matched the query, in doc sub-sections. The fields return depend
on the parameters of the query (and the defaults of the request handler used). The number of results is also
included in this section.
This screen allows you to experiment with different query options, and inspect how your documents were
indexed. The query parameters available on the form are some basic options that most users want to have
available, but there are dozens more available which could be simply added to the basic request by hand (if
opened in a browser). The table below explains the parameters available:
Field

Description

Request-handler
(qt)

Specifies the query handler for the request. If a query handler is not specified, Solr
processes the response with the standard query handler.

The query event. See Searching for an explanation of this parameter.

The filter queries. See Common Query Parameters for more information on this parameter.

sort

Sorts the response to a query in either ascending or descending order based on the
response's score or another specified characteristic.

start, rows

start is the offset into the query result starting at which documents should be returned.
The default value is 0, meaning that the query should return results starting with the first
document that matches. This field accepts the same syntax as the start query parameter,
which is described in Searching. rows is the number of rows to return.

Defines the fields to return for each document. You can explicitly list the stored fields, functi
ons, and doc transformers you want to have returned by separating them with either a
comma or a space.

Specifies the Response Writer to be used to format the query response. Defaults to XML if
not specified.

indent

Click this button to request that the Response Writer use indentation to make the
responses more readable.

debugQuery

Click this button to augment the query response with debugging information, including
"explain info" for each document returned. This debugging information is intended to be
intelligible to the administrator or programmer.

Apache Solr Reference Guide 5.1

dismax

Click this button to enable the Dismax query parser. See The DisMax Query Parser for
further information.

edismax

Click this button to enable the Extended query parser. See The Extended DisMax Query
Parser for further information.

Click this button to enable highlighting in the query response. See Highlighting for more
information.

facet

Enables faceting, the arrangement of search results into categories based on indexed
terms. See Faceting for more information.

spatial

Click to enable using location data for use in spatial or geospatial searches. See Spatial
Search for more information.

spellcheck

Click this button to enable the Spellchecker, which provides inline query suggestions based
on other, similar, terms. See Spell Checking for more information.

Apache Solr Ref Guide 5.1

Navigation menu

Versions of this User Manual:

Views

Navigation