Docs: Complete rewrite of setup, installation, and configuration docs
This commit is contained in:
parent
e85535724e
commit
06604708d4
|
@ -4,7 +4,7 @@
|
|||
:version: 5.0.0-alpha1
|
||||
:major-version: 5.x
|
||||
:branch: master
|
||||
:jdk: 1.8.0_25
|
||||
:jdk: 1.8.0_73
|
||||
:defguide: https://www.elastic.co/guide/en/elasticsearch/guide/current
|
||||
:plugins: https://www.elastic.co/guide/en/elasticsearch/plugins/master
|
||||
:javaclient: https://www.elastic.co/guide/en/elasticsearch/client/java-api/master/
|
||||
|
|
|
@ -297,6 +297,6 @@ same data directory. This can lead to unexpected data loss.
|
|||
== Other node settings
|
||||
|
||||
More node settings can be found in <<modules,Modules>>. Of particular note are
|
||||
the <<cluster-name,`cluster.name`>>, the <<node-name,`node.name`>> and the
|
||||
the <<cluster.name,`cluster.name`>>, the <<node.name,`node.name`>> and the
|
||||
<<modules-network,network settings>>.
|
||||
|
||||
|
|
|
@ -7,8 +7,8 @@ The following pages have moved or been deleted.
|
|||
=== Nodes shutdown
|
||||
|
||||
The `_shutdown` API has been removed. Instead, setup Elasticsearch to run as
|
||||
a service (see <<setup-service>> or <<setup-service-win>>) or use the `-p`
|
||||
command line option to <<setup-installation-pid,write the PID to a file>>.
|
||||
a service (see <<rpm>>, <<deb>>, or <<windows>>) or use the `-p`
|
||||
command line option to <<setup-installation-daemon,write the PID to a file>>.
|
||||
|
||||
[role="exclude",id="docs-bulk-udp"]
|
||||
=== Bulk UDP API
|
||||
|
|
|
@ -1,14 +1,15 @@
|
|||
[[setup]]
|
||||
= Setup
|
||||
= Setup Elasticsearch
|
||||
|
||||
[partintro]
|
||||
--
|
||||
This section includes information on how to setup *elasticsearch* and
|
||||
get it running. If you haven't already, http://www.elastic.co/downloads[download] it, and
|
||||
then check the <<setup-installation,installation>> docs.
|
||||
This section includes information on how to setup Elasticsearch and get it
|
||||
running, including:
|
||||
|
||||
NOTE: Elasticsearch can also be installed from our repositories using `apt` or `yum`.
|
||||
See <<setup-repositories>>.
|
||||
* Downloading
|
||||
* Installing
|
||||
* Starting
|
||||
* Configuring
|
||||
|
||||
[[supported-platforms]]
|
||||
[float]
|
||||
|
@ -18,89 +19,29 @@ The matrix of officially supported operating systems and JVMs is available here:
|
|||
link:/support/matrix[Support Matrix]. Elasticsearch is tested on the listed
|
||||
platforms, but it is possible that it will work on other platforms too.
|
||||
|
||||
[[setup-installation]]
|
||||
[float]
|
||||
== Installation
|
||||
|
||||
After link:/downloads/elasticsearch[downloading] the latest release and extracting it,
|
||||
*elasticsearch* can be started using:
|
||||
|
||||
[source,sh]
|
||||
--------------------------------------------------
|
||||
$ bin/elasticsearch
|
||||
--------------------------------------------------
|
||||
|
||||
On *nix systems, the command will start the process in the foreground.
|
||||
|
||||
[[setup-installation-daemon]]
|
||||
[float]
|
||||
=== Running as a daemon
|
||||
|
||||
To run it in the background, add the `-d` switch to it:
|
||||
|
||||
[source,sh]
|
||||
--------------------------------------------------
|
||||
$ bin/elasticsearch -d
|
||||
--------------------------------------------------
|
||||
|
||||
[[setup-installation-pid]]
|
||||
[float]
|
||||
=== PID
|
||||
|
||||
The Elasticsearch process can write its PID to a specified file on startup,
|
||||
making it easy to shut down the process later on:
|
||||
|
||||
[source,sh]
|
||||
--------------------------------------------------
|
||||
$ bin/elasticsearch -d -p pid <1>
|
||||
$ kill `cat pid` <2>
|
||||
--------------------------------------------------
|
||||
<1> The PID is written to a file called `pid`.
|
||||
<2> The `kill` command sends a `TERM` signal to the PID stored in the `pid` file.
|
||||
|
||||
NOTE: The startup scripts provided for <<setup-service,Linux>> and <<setup-service-win,Windows>>
|
||||
take care of starting and stopping the Elasticsearch process for you.
|
||||
|
||||
.*NIX
|
||||
*************************************************************************
|
||||
There are added features when using the `elasticsearch` shell script.
|
||||
The first, which was explained earlier, is the ability to easily run the
|
||||
process either in the foreground or the background.
|
||||
|
||||
Another feature is the ability to pass `-E` configuration parameters
|
||||
directly to the script. For example:
|
||||
|
||||
[source,sh]
|
||||
--------------------------------------------------
|
||||
$ bin/elasticsearch -Ees.index.refresh_interval=5s -Ees.node.name=my-node
|
||||
--------------------------------------------------
|
||||
*************************************************************************
|
||||
|
||||
[float]
|
||||
[[jvm-version]]
|
||||
== Java (JVM) version
|
||||
== Java (JVM) Version
|
||||
|
||||
Elasticsearch is built using Java, and requires at least
|
||||
http://www.oracle.com/technetwork/java/javase/downloads/index.html[Java 8] in
|
||||
order to run. Only Oracle's Java and the OpenJDK are supported. The same JVM
|
||||
version should be used on all Elasticsearch nodes and clients.
|
||||
|
||||
We recommend installing the *Java 8 update 20 or later*.
|
||||
Elasticsearch will refuse to start if a known-bad version of Java is used.
|
||||
We recommend installing Java version *{jdk} or later*. Elasticsearch will
|
||||
refuse to start if a known-bad version of Java is used.
|
||||
|
||||
The version of Java to use can be configured by setting the `JAVA_HOME`
|
||||
environment variable.
|
||||
The version of Java that Elasticsearch will use can be configured by setting
|
||||
the `JAVA_HOME` environment variable.
|
||||
|
||||
--
|
||||
|
||||
include::setup/install.asciidoc[]
|
||||
|
||||
include::setup/configuration.asciidoc[]
|
||||
|
||||
include::setup/as-a-service.asciidoc[]
|
||||
include::setup/important-settings.asciidoc[]
|
||||
|
||||
include::setup/as-a-service-win.asciidoc[]
|
||||
|
||||
include::setup/dir-layout.asciidoc[]
|
||||
|
||||
include::setup/repositories.asciidoc[]
|
||||
include::setup/sysconfig.asciidoc[]
|
||||
|
||||
include::setup/upgrade.asciidoc[]
|
||||
|
|
|
@ -1,67 +0,0 @@
|
|||
:backslash: \
|
||||
|
||||
[[setup-service-win]]
|
||||
== Running as a Service on Windows
|
||||
|
||||
Windows users can configure Elasticsearch to run as a service to run in the background or start automatically
|
||||
at startup without any user interaction.
|
||||
This can be achieved through `service.bat` script under `bin/` folder which allows one to install,
|
||||
remove, manage or configure the service and potentially start and stop the service, all from the command-line.
|
||||
|
||||
["source","sh",subs="attributes,callouts"]
|
||||
--------------------------------------------------
|
||||
c:\elasticsearch-{version}{backslash}bin>service
|
||||
|
||||
Usage: service.bat install|remove|start|stop|manager [SERVICE_ID]
|
||||
--------------------------------------------------
|
||||
|
||||
The script requires one parameter (the command to execute) followed by an optional one indicating the service
|
||||
id (useful when installing multiple Elasticsearch services).
|
||||
|
||||
The commands available are:
|
||||
|
||||
[horizontal]
|
||||
`install`:: Install Elasticsearch as a service
|
||||
|
||||
`remove`:: Remove the installed Elasticsearch service (and stop the service if started)
|
||||
|
||||
`start`:: Start the Elasticsearch service (if installed)
|
||||
|
||||
`stop`:: Stop the Elasticsearch service (if started)
|
||||
|
||||
`manager`:: Start a GUI for managing the installed service
|
||||
|
||||
Note that the environment configuration options available during the installation are copied and will be used during
|
||||
the service lifecycle. This means any changes made to them after the installation will not be picked up unless
|
||||
the service is reinstalled.
|
||||
|
||||
Based on the architecture of the available JDK/JRE (set through `JAVA_HOME`), the appropriate 64-bit(x64) or 32-bit(x86)
|
||||
service will be installed. This information is made available during install:
|
||||
|
||||
["source","sh",subs="attributes,callouts"]
|
||||
--------------------------------------------------
|
||||
c:\elasticsearch-{version}\bin>service install
|
||||
Installing service : "elasticsearch-service-x64"
|
||||
Using JAVA_HOME (64-bit): "c:\jvm\jdk1.8"
|
||||
The service 'elasticsearch-service-x64' has been installed.
|
||||
--------------------------------------------------
|
||||
|
||||
NOTE: While a JRE can be used for the Elasticsearch service, due to its use of a client VM (as oppose to a server JVM which
|
||||
offers better performance for long-running applications) its usage is discouraged and a warning will be issued.
|
||||
|
||||
[float]
|
||||
=== Customizing service settings
|
||||
|
||||
There are two ways to customize the service settings:
|
||||
|
||||
Manager GUI:: accessible through `manager` command, the GUI offers insight into the installed service including its status, startup type,
|
||||
JVM, start and stop settings among other things. Simply invoking `service.bat` from the command-line with the aforementioned option
|
||||
will open up the manager window:
|
||||
|
||||
image::images/service-manager-win.png["Windows Service Manager GUI",align="center"]
|
||||
|
||||
Customizing `service.bat`:: at its core, `service.bat` relies on http://commons.apache.org/proper/commons-daemon/[Apache Commons Daemon] project
|
||||
to install the services. For full flexibility such as customizing the user under which the service runs, one can modify the installation
|
||||
parameters to tweak all the parameters accordingly. Do note that this requires reinstalling the service for the new settings to be applied.
|
||||
|
||||
NOTE: There is also a community supported customizable MSI installer available: https://github.com/salyh/elasticsearch-msi-installer (by Hendrik Saly).
|
|
@ -1,87 +0,0 @@
|
|||
[[setup-service]]
|
||||
== Running as a Service on Linux
|
||||
|
||||
In order to run elasticsearch as a service on your operating system, the provided packages try to make it as easy as possible for you to start and stop elasticsearch during reboot and upgrades.
|
||||
|
||||
[float]
|
||||
=== Linux
|
||||
|
||||
Currently our build automatically creates a debian package and an RPM package, which is available on the download page. The package itself does not have any dependencies, but you have to make sure that you installed a JDK.
|
||||
|
||||
Each package features a configuration file, which allows you to set the following parameters
|
||||
|
||||
[horizontal]
|
||||
`ES_USER`:: The user to run as, defaults to `elasticsearch`
|
||||
`ES_GROUP`:: The group to run as, defaults to `elasticsearch`
|
||||
`ES_HEAP_SIZE`:: The heap size to start with
|
||||
`ES_HEAP_NEWSIZE`:: The size of the new generation heap
|
||||
`ES_DIRECT_SIZE`:: The maximum size of the direct memory
|
||||
`MAX_OPEN_FILES`:: Maximum number of open files, defaults to `65536`
|
||||
`MAX_LOCKED_MEMORY`:: Maximum locked memory size. Set to "unlimited" if you use the bootstrap.mlockall option in elasticsearch.yml. You must also set ES_HEAP_SIZE.
|
||||
`MAX_MAP_COUNT`:: Maximum number of memory map areas a process may have. If you use `mmapfs` as index store type, make sure this is set to a high value. For more information, check the https://github.com/torvalds/linux/blob/master/Documentation/sysctl/vm.txt[linux kernel documentation] about `max_map_count`. This is set via `sysctl` before starting elasticsearch. Defaults to `65535`
|
||||
`LOG_DIR`:: Log directory, defaults to `/var/log/elasticsearch`
|
||||
`DATA_DIR`:: Data directory, defaults to `/var/lib/elasticsearch`
|
||||
`CONF_DIR`:: Configuration file directory (which needs to include `elasticsearch.yml` and `logging.yml` files), defaults to `/etc/elasticsearch`
|
||||
`ES_JAVA_OPTS`:: Any additional java options you may want to apply. This may be useful, if you need to set the `node.name` property, but do not want to change the `elasticsearch.yml` configuration file, because it is distributed via a provisioning system like puppet or chef. Example: `ES_JAVA_OPTS="-Des.node.name=search-01"`
|
||||
`RESTART_ON_UPGRADE`:: Configure restart on package upgrade, defaults to `false`. This means you will have to restart your elasticsearch instance after installing a package manually. The reason for this is to ensure, that upgrades in a cluster do not result in a continuous shard reallocation resulting in high network traffic and reducing the response times of your cluster.
|
||||
`ES_GC_LOG_FILE` :: The absolute log file path for creating a garbage collection logfile, which is done by the JVM. Note that this logfile can grow pretty quick and thus is disabled by default.
|
||||
|
||||
[float]
|
||||
==== Debian/Ubuntu
|
||||
|
||||
The debian package ships with everything you need as it uses standard debian tools like update `update-rc.d` to define the runlevels it runs on. The init script is placed at `/etc/init.d/elasticsearch` as you would expect it. The configuration file is placed at `/etc/default/elasticsearch`.
|
||||
|
||||
The debian package does not start up the service by default. The reason for this is to prevent the instance to accidentally join a cluster, without being configured appropriately. After installing using `dpkg -i` you can use the following commands to ensure, that elasticsearch starts when the system is booted and then start up elasticsearch:
|
||||
|
||||
[source,sh]
|
||||
--------------------------------------------------
|
||||
sudo update-rc.d elasticsearch defaults 95 10
|
||||
sudo /etc/init.d/elasticsearch start
|
||||
--------------------------------------------------
|
||||
|
||||
Users running Debian 8 or Ubuntu 14 or later may require configuration of systemd instead of `update-rc.d`. In those cases, please refer to the <<using-systemd>> section.
|
||||
|
||||
[float]
|
||||
===== Installing the oracle JDK
|
||||
|
||||
The usual recommendation is to run the Oracle JDK with elasticsearch. However Ubuntu and Debian only ship the OpenJDK due to license issues. You can easily install the oracle installer package though. In case you are missing the `add-apt-repository` command under Debian GNU/Linux, make sure have at least Debian Jessie and the package `python-software-properties` installed
|
||||
|
||||
[source,sh]
|
||||
--------------------------------------------------
|
||||
sudo add-apt-repository ppa:webupd8team/java
|
||||
sudo apt-get update
|
||||
sudo apt-get install oracle-java8-installer
|
||||
java -version
|
||||
--------------------------------------------------
|
||||
|
||||
The last command should verify a successful installation of the Oracle JDK.
|
||||
|
||||
|
||||
[float]
|
||||
==== RPM based distributions
|
||||
|
||||
[float]
|
||||
===== Using chkconfig
|
||||
|
||||
Some RPM based distributions are using `chkconfig` to enable and disable services. The init script is located at `/etc/init.d/elasticsearch`, where as the configuration file is placed at `/etc/sysconfig/elasticsearch`. Like the debian package the RPM package is not started by default after installation, you have to do this manually by entering the following commands
|
||||
|
||||
[source,sh]
|
||||
--------------------------------------------------
|
||||
sudo /sbin/chkconfig --add elasticsearch
|
||||
sudo service elasticsearch start
|
||||
--------------------------------------------------
|
||||
|
||||
[[using-systemd]]
|
||||
[float]
|
||||
==== Using systemd
|
||||
|
||||
Distributions like Debian Jessie, Ubuntu 14, and many of the SUSE derivatives do not use the `chkconfig` tool to register services, but rather `systemd` and its command `/bin/systemctl` to start and stop services (at least in newer versions, otherwise use the `chkconfig` commands above). The configuration file is also placed at `/etc/sysconfig/elasticsearch` if the system is rpm based and `/etc/default/elasticsearch` if it is deb. After installing the RPM, you have to change the systemd configuration and then start up elasticsearch
|
||||
|
||||
[source,sh]
|
||||
--------------------------------------------------
|
||||
sudo /bin/systemctl daemon-reload
|
||||
sudo /bin/systemctl enable elasticsearch.service
|
||||
sudo /bin/systemctl start elasticsearch.service
|
||||
--------------------------------------------------
|
||||
|
||||
Also note that changing the `MAX_MAP_COUNT` setting in `/etc/sysconfig/elasticsearch` does not have any effect, you will have to change it in `/usr/lib/sysctl.d/elasticsearch.conf` in order to have it applied at startup.
|
|
@ -1,86 +0,0 @@
|
|||
[[backup]]
|
||||
=== Back Up Your Data!
|
||||
|
||||
Always back up your data before performing an upgrade. This will allow you to
|
||||
roll back in the event of a problem. The upgrades sometimes include upgrades
|
||||
to the Lucene libraries used by Elasticsearch to access the index files, and
|
||||
after an index file has been updated to work with a new version of Lucene, it
|
||||
may not be accessible to the versions of Lucene present in earlier
|
||||
Elasticsearch releases.
|
||||
|
||||
[WARNING]
|
||||
.Always back up your data before upgrading
|
||||
=========================================
|
||||
You cannot roll back to an earlier version unless you have a backup of your data.
|
||||
=========================================
|
||||
|
||||
==== Backing up 1.0 and later
|
||||
|
||||
To back up a running 1.0 or later system, it is simplest to use the snapshot
|
||||
feature. See the complete instructions for
|
||||
<<modules-snapshots,backup and restore with snapshots>>.
|
||||
|
||||
==== Backing up 0.90.x and earlier
|
||||
|
||||
To back up a running 0.90.x system:
|
||||
|
||||
===== Step 1: Disable index flushing
|
||||
|
||||
This will prevent indices from being flushed to disk while the backup is in
|
||||
process:
|
||||
|
||||
[source,js]
|
||||
-----------------------------------
|
||||
PUT /_all/_settings
|
||||
{
|
||||
"index": {
|
||||
"translog.disable_flush": "true"
|
||||
}
|
||||
}
|
||||
-----------------------------------
|
||||
// AUTOSENSE
|
||||
|
||||
===== Step 2: Disable reallocation
|
||||
|
||||
This will prevent the cluster from moving data files from one node to another
|
||||
while the backup is in process:
|
||||
|
||||
[source,js]
|
||||
-----------------------------------
|
||||
PUT /_cluster/settings
|
||||
{
|
||||
"transient": {
|
||||
"cluster.routing.allocation.enable": "none"
|
||||
}
|
||||
}
|
||||
-----------------------------------
|
||||
// AUTOSENSE
|
||||
|
||||
===== Step 3: Backup your data
|
||||
|
||||
After reallocation and index flushing are disabled, initiate a backup of
|
||||
Elasticsearch's data path using your favorite backup method (tar, storage
|
||||
array snapshots, backup software).
|
||||
|
||||
===== Step 4: Reenable allocation and flushing
|
||||
|
||||
When the backup is complete and data no longer needs to be read from the
|
||||
Elasticsearch data path, allocation and index flushing must be re-enabled:
|
||||
|
||||
[source,js]
|
||||
-----------------------------------
|
||||
PUT /_all/_settings
|
||||
{
|
||||
"index": {
|
||||
"translog.disable_flush": "false"
|
||||
}
|
||||
}
|
||||
|
||||
PUT /_cluster/settings
|
||||
{
|
||||
"transient": {
|
||||
"cluster.routing.allocation.enable": "all"
|
||||
}
|
||||
}
|
||||
-----------------------------------
|
||||
// AUTOSENSE
|
|
@ -2,8 +2,9 @@
|
|||
=== Full cluster restart upgrade
|
||||
|
||||
Elasticsearch requires a full cluster restart when upgrading across major
|
||||
versions: from 0.x to 1.x or from 1.x to 2.x. Rolling upgrades are not
|
||||
supported across major versions.
|
||||
versions. Rolling upgrades are not supported across major versions. Consult
|
||||
this <<setup-upgrade,table>> to verify that a full cluster restart is
|
||||
required.
|
||||
|
||||
The process to perform an upgrade with a full cluster restart is as follows:
|
||||
|
||||
|
@ -25,20 +26,6 @@ PUT /_cluster/settings
|
|||
--------------------------------------------------
|
||||
// AUTOSENSE
|
||||
|
||||
If upgrading from 0.90.x to 1.x, then use these settings instead:
|
||||
|
||||
[source,js]
|
||||
--------------------------------------------------
|
||||
PUT /_cluster/settings
|
||||
{
|
||||
"persistent": {
|
||||
"cluster.routing.allocation.disable_allocation": true,
|
||||
"cluster.routing.allocation.enable": "none"
|
||||
}
|
||||
}
|
||||
--------------------------------------------------
|
||||
// AUTOSENSE
|
||||
|
||||
==== Step 2: Perform a synced flush
|
||||
|
||||
Shard recovery will be much faster if you stop indexing and issue a
|
||||
|
@ -59,7 +46,13 @@ multiple times if necessary.
|
|||
Stop all Elasticsearch services on all nodes in the cluster. Each node can be
|
||||
upgraded following the same procedure described in <<upgrade-node>>.
|
||||
|
||||
==== Step 4: Start the cluster
|
||||
==== Step 4: Upgrade any plugins
|
||||
|
||||
Elasticsearch plugins must be upgraded when upgrading a node. Use the
|
||||
`elasticsearch-plugin` script to install the correct version of any plugins
|
||||
that you need.
|
||||
|
||||
==== Step 5: Start the cluster
|
||||
|
||||
If you have dedicated master nodes -- nodes with `node.master` set to
|
||||
`true`(the default) and `node.data` set to `false` -- then it is a good idea
|
||||
|
@ -82,7 +75,7 @@ GET _cat/nodes
|
|||
|
||||
Use these APIs to check that all nodes have successfully joined the cluster.
|
||||
|
||||
==== Step 5: Wait for yellow
|
||||
==== Step 6: Wait for yellow
|
||||
|
||||
As soon as each node has joined the cluster, it will start to recover any
|
||||
primary shards that are stored locally. Initially, the
|
||||
|
@ -94,7 +87,7 @@ Once each node has recovered its local shards, the `status` will become
|
|||
shards are allocated. This is to be expected because allocation is still
|
||||
disabled.
|
||||
|
||||
==== Step 6: Reenable allocation
|
||||
==== Step 7: Reenable allocation
|
||||
|
||||
Delaying the allocation of replicas until all nodes have joined the cluster
|
||||
allows the master to allocate replicas to nodes which already have local shard
|
||||
|
@ -112,20 +105,6 @@ PUT /_cluster/settings
|
|||
------------------------------------------------------
|
||||
// AUTOSENSE
|
||||
|
||||
If upgrading from 0.90.x to 1.x, then use these settings instead:
|
||||
|
||||
[source,js]
|
||||
--------------------------------------------------
|
||||
PUT /_cluster/settings
|
||||
{
|
||||
"persistent": {
|
||||
"cluster.routing.allocation.disable_allocation": false,
|
||||
"cluster.routing.allocation.enable": "all"
|
||||
}
|
||||
}
|
||||
--------------------------------------------------
|
||||
// AUTOSENSE
|
||||
|
||||
The cluster will now start allocating replica shards to all data nodes. At this
|
||||
point it is safe to resume indexing and searching, but your cluster will
|
||||
recover more quickly if you can delay indexing and searching until all shards
|
||||
|
|
|
@ -1,288 +1,76 @@
|
|||
[[setup-configuration]]
|
||||
== Configuration
|
||||
|
||||
[float]
|
||||
=== Environment Variables
|
||||
|
||||
Within the scripts, Elasticsearch comes with built in `JAVA_OPTS` passed
|
||||
to the JVM started. The most important setting for that is the `-Xmx` to
|
||||
control the maximum allowed memory for the process, and `-Xms` to
|
||||
control the minimum allocated memory for the process (_in general, the
|
||||
more memory allocated to the process, the better_).
|
||||
|
||||
Most times it is better to leave the default `JAVA_OPTS` as they are,
|
||||
and use the `ES_JAVA_OPTS` environment variable in order to set / change
|
||||
JVM settings or arguments.
|
||||
|
||||
The `ES_HEAP_SIZE` environment variable allows to set the heap memory
|
||||
that will be allocated to elasticsearch java process. It will allocate
|
||||
the same value to both min and max values, though those can be set
|
||||
explicitly (not recommended) by setting `ES_MIN_MEM` (defaults to
|
||||
`256m`), and `ES_MAX_MEM` (defaults to `1g`).
|
||||
|
||||
It is recommended to set the min and max memory to the same value, and
|
||||
enable <<setup-configuration-memory,`mlockall`>>.
|
||||
|
||||
[float]
|
||||
[[system]]
|
||||
=== System Configuration
|
||||
|
||||
[float]
|
||||
[[file-descriptors]]
|
||||
==== File Descriptors
|
||||
|
||||
Make sure to increase the number of open files descriptors on the
|
||||
machine (or for the user running elasticsearch). Setting it to 32k or
|
||||
even 64k is recommended.
|
||||
|
||||
You can retrieve the `max_file_descriptors` for each node
|
||||
using the <<cluster-nodes-info>> API, with:
|
||||
|
||||
[source,js]
|
||||
--------------------------------------------------
|
||||
curl localhost:9200/_nodes/stats/process?pretty
|
||||
--------------------------------------------------
|
||||
|
||||
[float]
|
||||
[[max-number-of-threads]]
|
||||
==== Number of threads
|
||||
|
||||
Make sure that the number of threads that the Elasticsearch user can
|
||||
create is at least 2048.
|
||||
|
||||
[float]
|
||||
[[vm-max-map-count]]
|
||||
==== Virtual memory
|
||||
|
||||
Elasticsearch uses a <<default_fs,`hybrid mmapfs / niofs`>> directory by default to store its indices. The default
|
||||
operating system limits on mmap counts is likely to be too low, which may
|
||||
result in out of memory exceptions. On Linux, you can increase the limits by
|
||||
running the following command as `root`:
|
||||
|
||||
[source,sh]
|
||||
-------------------------------------
|
||||
sysctl -w vm.max_map_count=262144
|
||||
-------------------------------------
|
||||
|
||||
To set this value permanently, update the `vm.max_map_count` setting in
|
||||
`/etc/sysctl.conf`.
|
||||
|
||||
NOTE: If you installed Elasticsearch using a package (.deb, .rpm) this setting will be changed automatically. To verify, run `sysctl vm.max_map_count`.
|
||||
|
||||
[float]
|
||||
[[setup-configuration-memory]]
|
||||
==== Memory Settings
|
||||
|
||||
Most operating systems try to use as much memory as possible for file system
|
||||
caches and eagerly swap out unused application memory, possibly resulting
|
||||
in the elasticsearch process being swapped. Swapping is very bad for
|
||||
performance and for node stability, so it should be avoided at all costs.
|
||||
|
||||
There are three options:
|
||||
|
||||
* **Disable swap**
|
||||
+
|
||||
--
|
||||
|
||||
The simplest option is to completely disable swap. Usually Elasticsearch
|
||||
is the only service running on a box, and its memory usage is controlled
|
||||
by the `ES_HEAP_SIZE` environment variable. There should be no need
|
||||
to have swap enabled.
|
||||
|
||||
On Linux systems, you can disable swap temporarily
|
||||
by running: `sudo swapoff -a`. To disable it permanently, you will need
|
||||
to edit the `/etc/fstab` file and comment out any lines that contain the
|
||||
word `swap`.
|
||||
|
||||
On Windows, the equivalent can be achieved by disabling the paging file entirely
|
||||
via `System Properties → Advanced → Performance → Advanced → Virtual memory`.
|
||||
|
||||
--
|
||||
|
||||
* **Configure `swappiness`**
|
||||
+
|
||||
--
|
||||
The second option is to ensure that the sysctl value `vm.swappiness` is set
|
||||
to `0`. This reduces the kernel's tendency to swap and should not lead to
|
||||
swapping under normal circumstances, while still allowing the whole system
|
||||
to swap in emergency conditions.
|
||||
|
||||
NOTE: From kernel version 3.5-rc1 and above, a `swappiness` of `0` will
|
||||
cause the OOM killer to kill the process instead of allowing swapping.
|
||||
You will need to set `swappiness` to `1` to still allow swapping in
|
||||
emergencies.
|
||||
--
|
||||
|
||||
* **`mlockall`**
|
||||
+
|
||||
--
|
||||
The third option is to use
|
||||
http://opengroup.org/onlinepubs/007908799/xsh/mlockall.html[mlockall] on Linux/Unix systems, or https://msdn.microsoft.com/en-us/library/windows/desktop/aa366895%28v=vs.85%29.aspx[VirtualLock] on Windows, to
|
||||
try to lock the process address space into RAM, preventing any Elasticsearch
|
||||
memory from being swapped out. This can be done, by adding this line
|
||||
to the `config/elasticsearch.yml` file:
|
||||
|
||||
[source,yaml]
|
||||
--------------
|
||||
bootstrap.mlockall: true
|
||||
--------------
|
||||
|
||||
After starting Elasticsearch, you can see whether this setting was applied
|
||||
successfully by checking the value of `mlockall` in the output from this
|
||||
request:
|
||||
|
||||
[source,sh]
|
||||
--------------
|
||||
curl http://localhost:9200/_nodes/process?pretty
|
||||
--------------
|
||||
|
||||
If you see that `mlockall` is `false`, then it means that the `mlockall`
|
||||
request has failed. The most probable reason, on Linux/Unix systems, is that
|
||||
the user running Elasticsearch doesn't have permission to lock memory. This can
|
||||
be granted by running `ulimit -l unlimited` as `root` before starting Elasticsearch.
|
||||
|
||||
Another possible reason why `mlockall` can fail is that the temporary directory
|
||||
(usually `/tmp`) is mounted with the `noexec` option. This can be solved by
|
||||
specifying a new temp directory, by starting Elasticsearch with:
|
||||
|
||||
[source,sh]
|
||||
--------------
|
||||
./bin/elasticsearch -Djna.tmpdir=/path/to/new/dir
|
||||
--------------
|
||||
|
||||
WARNING: `mlockall` might cause the JVM or shell session to exit if it tries
|
||||
to allocate more memory than is available!
|
||||
--
|
||||
|
||||
[float]
|
||||
[[settings]]
|
||||
=== Elasticsearch Settings
|
||||
== Configuring Elasticsearch
|
||||
|
||||
*elasticsearch* configuration files can be found under `ES_HOME/config`
|
||||
folder. The folder comes with two files, the `elasticsearch.yml` for
|
||||
configuring Elasticsearch different
|
||||
<<modules,modules>>, and `logging.yml` for
|
||||
configuring the Elasticsearch logging.
|
||||
Elasticsearch ships with good defaults and requires very little configuration.
|
||||
Most settings can be changed on a running cluster using the
|
||||
<<cluster-update-settings>> API.
|
||||
|
||||
The configuration files should contain settings which are node-specific (such
|
||||
as `node.name` and paths), or settings which a node requires in order to be
|
||||
able to join a cluster, such as `cluster.name` and `network.host`.
|
||||
|
||||
[float]
|
||||
=== Config file location
|
||||
|
||||
Elasticsearch has two configuration files:
|
||||
|
||||
* `elasticsearch.yml` for configuring Elasticsearch, and
|
||||
* `logging.yml` for configuring Elasticsearch logging.
|
||||
|
||||
These files are located in the config directory, whose location defaults to
|
||||
`$ES_HOME/config/`. The Debian and RPM packages set the config directory
|
||||
location to `/etc/elasticsearch/`.
|
||||
|
||||
The location of the config directory can be changed with the `path.conf`
|
||||
setting, as follows:
|
||||
|
||||
[source,sh]
|
||||
-------------------------------
|
||||
./bin/elasticsearch -E es.path.conf=/path/to/my/config/
|
||||
-------------------------------
|
||||
|
||||
[float]
|
||||
=== Config file format
|
||||
|
||||
The configuration format is http://www.yaml.org/[YAML]. Here is an
|
||||
example of changing the address all network based modules will use to
|
||||
bind and publish to:
|
||||
|
||||
[source,yaml]
|
||||
--------------------------------------------------
|
||||
network :
|
||||
host : 10.0.0.4
|
||||
--------------------------------------------------
|
||||
|
||||
|
||||
[float]
|
||||
[[paths]]
|
||||
==== Paths
|
||||
|
||||
In production use, you will almost certainly want to change paths for
|
||||
data and log files:
|
||||
example of changing the path of the data and logs directories:
|
||||
|
||||
[source,yaml]
|
||||
--------------------------------------------------
|
||||
path:
|
||||
logs: /var/log/elasticsearch
|
||||
data: /var/data/elasticsearch
|
||||
data: /var/lib/elasticsearch
|
||||
logs: /var/logs/elasticsearch
|
||||
--------------------------------------------------
|
||||
|
||||
Settings can also be flattened as follows:
|
||||
|
||||
[source,yaml]
|
||||
--------------------------------------------------
|
||||
path.data: /var/lib/elasticsearch
|
||||
path.logs: /var/logs/elasticsearch
|
||||
--------------------------------------------------
|
||||
|
||||
[float]
|
||||
[[cluster-name]]
|
||||
==== Cluster name
|
||||
=== Environment variable subsitution
|
||||
|
||||
Also, don't forget to give your production cluster a name, which is used
|
||||
to discover and auto-join other nodes:
|
||||
Environment variables referenced with the `${...}` notation within the
|
||||
configuration file will be replaced with the value of the environment
|
||||
variable, for instance:
|
||||
|
||||
[source,yaml]
|
||||
--------------------------------------------------
|
||||
cluster:
|
||||
name: <NAME OF YOUR CLUSTER>
|
||||
node.name: ${HOSTNAME}
|
||||
network.host: ${ES_NETWORK_HOST}
|
||||
--------------------------------------------------
|
||||
|
||||
Make sure that you don't reuse the same cluster names in different
|
||||
environments, otherwise you might end up with nodes joining the wrong cluster.
|
||||
For instance you could use `logging-dev`, `logging-stage`, and `logging-prod`
|
||||
for the development, staging, and production clusters.
|
||||
|
||||
[float]
|
||||
[[node-name]]
|
||||
==== Node name
|
||||
=== Prompting for settings
|
||||
|
||||
You may also want to change the default node name for each node to
|
||||
something like the display hostname. By default Elasticsearch will
|
||||
randomly pick a Marvel character name from a list of around 3000 names
|
||||
when your node starts up.
|
||||
|
||||
[source,yaml]
|
||||
--------------------------------------------------
|
||||
node:
|
||||
name: <NAME OF YOUR NODE>
|
||||
--------------------------------------------------
|
||||
|
||||
The hostname of the machine is provided in the environment
|
||||
variable `HOSTNAME`. If on your machine you only run a
|
||||
single elasticsearch node for that cluster, you can set
|
||||
the node name to the hostname using the `${...}` notation:
|
||||
|
||||
[source,yaml]
|
||||
--------------------------------------------------
|
||||
node:
|
||||
name: ${HOSTNAME}
|
||||
--------------------------------------------------
|
||||
|
||||
Internally, all settings are collapsed into "namespaced" settings. For
|
||||
example, the above gets collapsed into `node.name`. This means that
|
||||
its easy to support other configuration formats, for example,
|
||||
http://www.json.org[JSON]. If JSON is a preferred configuration format,
|
||||
simply rename the `elasticsearch.yml` file to `elasticsearch.json` and
|
||||
add:
|
||||
|
||||
[float]
|
||||
[[styles]]
|
||||
==== Configuration styles
|
||||
|
||||
[source,yaml]
|
||||
--------------------------------------------------
|
||||
{
|
||||
"network" : {
|
||||
"host" : "10.0.0.4"
|
||||
}
|
||||
}
|
||||
--------------------------------------------------
|
||||
|
||||
It also means that its easy to provide the settings externally either
|
||||
using the `ES_JAVA_OPTS` or as parameters to the `elasticsearch`
|
||||
command, for example:
|
||||
|
||||
[source,sh]
|
||||
--------------------------------------------------
|
||||
$ elasticsearch -Ees.network.host=10.0.0.4
|
||||
--------------------------------------------------
|
||||
|
||||
Another option is to set `es.default.` prefix instead of `es.` prefix,
|
||||
which means the default setting will be used only if not explicitly set
|
||||
in the configuration file.
|
||||
|
||||
Another option is to use the `${...}` notation within the configuration
|
||||
file which will resolve to an environment setting, for example:
|
||||
|
||||
[source,js]
|
||||
--------------------------------------------------
|
||||
{
|
||||
"network" : {
|
||||
"host" : "${ES_NET_HOST}"
|
||||
}
|
||||
}
|
||||
--------------------------------------------------
|
||||
|
||||
Additionally, for settings that you do not wish to store in the configuration
|
||||
file, you can use the value `${prompt.text}` or `${prompt.secret}` and start
|
||||
Elasticsearch in the foreground. `${prompt.secret}` has echoing disabled so
|
||||
that the value entered will not be shown in your terminal; `${prompt.text}`
|
||||
will allow you to see the value as you type it in. For example:
|
||||
For settings that you do not wish to store in the configuration file, you can
|
||||
use the value `${prompt.text}` or `${prompt.secret}` and start Elasticsearch
|
||||
in the foreground. `${prompt.secret}` has echoing disabled so that the value
|
||||
entered will not be shown in your terminal; `${prompt.text}` will allow you to
|
||||
see the value as you type it in. For example:
|
||||
|
||||
[source,yaml]
|
||||
--------------------------------------------------
|
||||
|
@ -290,8 +78,8 @@ node:
|
|||
name: ${prompt.text}
|
||||
--------------------------------------------------
|
||||
|
||||
On execution of the `elasticsearch` command, you will be prompted to enter
|
||||
the actual value like so:
|
||||
When starting Elasticsearch, you will be prompted to enter the actual value
|
||||
like so:
|
||||
|
||||
[source,sh]
|
||||
--------------------------------------------------
|
||||
|
@ -302,49 +90,26 @@ NOTE: Elasticsearch will not start if `${prompt.text}` or `${prompt.secret}`
|
|||
is used in the settings and the process is run as a service or in the background.
|
||||
|
||||
[float]
|
||||
[[configuration-index-settings]]
|
||||
=== Index Settings
|
||||
=== Setting default settings
|
||||
|
||||
Indices created within the cluster can provide their own settings. For
|
||||
example, the following creates an index with a refresh interval of 5
|
||||
seconds instead of the default refresh interval (the format can be either
|
||||
YAML or JSON):
|
||||
New default settings may be specified on the command line using the
|
||||
`es.default.` prefix instead of the `es.` prefix. This will specify a value
|
||||
that will be used by default unless another value is specified in the config
|
||||
file.
|
||||
|
||||
For instance, if Elasticsearch is started as follows:
|
||||
|
||||
[source,sh]
|
||||
--------------------------------------------------
|
||||
$ curl -XPUT http://localhost:9200/kimchy/ -d \
|
||||
'
|
||||
index:
|
||||
refresh_interval: 5s
|
||||
'
|
||||
--------------------------------------------------
|
||||
---------------------------
|
||||
./bin/elasticsearch -E es.default.node.name=My_Node
|
||||
---------------------------
|
||||
|
||||
Index level settings can be set on the node level as well, for example,
|
||||
within the `elasticsearch.yml` file, the following can be set:
|
||||
|
||||
[source,yaml]
|
||||
--------------------------------------------------
|
||||
index :
|
||||
refresh_interval: 5s
|
||||
--------------------------------------------------
|
||||
|
||||
This means that every index that gets created on the specific node
|
||||
started with the mentioned configuration will use a refresh interval of
|
||||
5 seconds *unless the index explicitly sets it*. In other words, any
|
||||
index level settings override what is set in the node configuration. Of
|
||||
course, the above can also be set as a "collapsed" setting, for example:
|
||||
|
||||
[source,sh]
|
||||
--------------------------------------------------
|
||||
$ elasticsearch -Ees.index.refresh_interval=5s
|
||||
--------------------------------------------------
|
||||
|
||||
All of the index level configuration can be found within each
|
||||
<<index-modules,index module>>.
|
||||
the value for `node.name` will be `My_Node`, unless it is overwritten on the
|
||||
command line with `es.node.name` or in the config file with `node.name`.
|
||||
|
||||
[float]
|
||||
[[logging]]
|
||||
=== Logging
|
||||
== Logging configuration
|
||||
|
||||
Elasticsearch uses an internal logging abstraction and comes, out of the
|
||||
box, with http://logging.apache.org/log4j/1.2/[log4j]. It tries to simplify
|
||||
|
@ -367,7 +132,7 @@ out of the box.
|
|||
|
||||
[float]
|
||||
[[deprecation-logging]]
|
||||
==== Deprecation logging
|
||||
=== Deprecation logging
|
||||
|
||||
In addition to regular logging, Elasticsearch allows you to enable logging
|
||||
of deprecated actions. For example this allows you to determine early, if
|
||||
|
|
|
@ -1,97 +0,0 @@
|
|||
[[setup-dir-layout]]
|
||||
== Directory Layout
|
||||
|
||||
The directory layout of an installation is as follows:
|
||||
|
||||
[cols="<h,<,<m,<m",options="header",]
|
||||
|=======================================================================
|
||||
| Type | Description | Default Location | Setting
|
||||
| home | Home of elasticsearch installation. | | path.home
|
||||
|
||||
| bin | Binary scripts including `elasticsearch` to start a node. | {path.home}/bin | | conf | Configuration files including `elasticsearch.yml` | {path.home}/config | path.conf
|
||||
|
||||
| data | The location of the data files of each index / shard allocated
|
||||
on the node. Can hold multiple locations. | {path.home}/data| path.data
|
||||
|
||||
| logs | Log files location. | {path.home}/logs | path.logs
|
||||
|
||||
| plugins | Plugin files location. Each plugin will be contained in a subdirectory. | {path.home}/plugins | path.plugins
|
||||
|
||||
| repo | Shared file system repository locations. Can hold multiple locations. A file system repository can be placed in to any subdirectory of any directory specified here. d| Not configured | path.repo
|
||||
|
||||
| script | Location of script files. | {path.conf}/scripts | path.script
|
||||
|
||||
|=======================================================================
|
||||
|
||||
Multiple `data` paths may be specified, in order to spread data across
|
||||
multiple disks or locations, but all of the files from a single shard will be
|
||||
written to the same path. This can be configured as follows:
|
||||
|
||||
---------------------------------
|
||||
path.data: /mnt/first,/mnt/second
|
||||
---------------------------------
|
||||
|
||||
Or in an array format:
|
||||
|
||||
----------------------------------------
|
||||
path.data: ["/mnt/first", "/mnt/second"]
|
||||
----------------------------------------
|
||||
|
||||
TIP: To stripe shards across multiple disks, please use a RAID driver
|
||||
instead.
|
||||
|
||||
[float]
|
||||
[[default-paths]]
|
||||
=== Default Paths
|
||||
|
||||
Below are the default paths that elasticsearch will use, if not explicitly changed.
|
||||
|
||||
[float]
|
||||
==== deb and rpm
|
||||
[cols="<h,<,<m,<m",options="header",]
|
||||
|=======================================================================
|
||||
| Type | Description | Location Debian/Ubuntu | Location RHEL/CentOS
|
||||
| home | Home of elasticsearch installation. | /usr/share/elasticsearch | /usr/share/elasticsearch
|
||||
|
||||
| bin | Binary scripts including `elasticsearch` to start a node. | /usr/share/elasticsearch/bin | /usr/share/elasticsearch/bin
|
||||
|
||||
| conf | Configuration files `elasticsearch.yml` and `logging.yml`. | /etc/elasticsearch | /etc/elasticsearch
|
||||
|
||||
| conf | Environment variables including heap size, file descriptors. | /etc/default/elasticsearch | /etc/sysconfig/elasticsearch
|
||||
|
||||
| data | The location of the data files of each index / shard allocated
|
||||
on the node. | /var/lib/elasticsearch/data | /var/lib/elasticsearch
|
||||
|
||||
| logs | Log files location | /var/log/elasticsearch | /var/log/elasticsearch
|
||||
|
||||
| plugins | Plugin files location. Each plugin will be contained in a subdirectory. | /usr/share/elasticsearch/plugins | /usr/share/elasticsearch/plugins
|
||||
|
||||
| repo | Shared file system repository locations. d| Not configured d| Not configured
|
||||
|
||||
| script | Location of script files. | /etc/elasticsearch/scripts | /etc/elasticsearch/scripts
|
||||
|
||||
|=======================================================================
|
||||
|
||||
[float]
|
||||
==== zip and tar.gz
|
||||
[cols="<h,<,<m",options="header",]
|
||||
|=======================================================================
|
||||
| Type | Description | Location
|
||||
| home | Home of elasticsearch installation | {extract.path}
|
||||
|
||||
| bin | Binary scripts including `elasticsearch` to start a node | {extract.path}/bin
|
||||
|
||||
| conf | Configuration files `elasticsearch.yml` and `logging.yml` | {extract.path}/config
|
||||
|
||||
| data | The location of the data files of each index / shard allocated
|
||||
on the node | {extract.path}/data
|
||||
|
||||
| logs | Log files location | {extract.path}/logs
|
||||
|
||||
| plugins | Plugin files location. Each plugin will be contained in a subdirectory | {extract.path}/plugins
|
||||
|
||||
| repo | Shared file system repository locations. d| Not configured
|
||||
|
||||
| script | Location of script files. | {extract.path}/config/scripts
|
||||
|
||||
|=======================================================================
|
|
@ -0,0 +1,216 @@
|
|||
[[important-settings]]
|
||||
== Important Elasticsearch configuration
|
||||
|
||||
While Elasticsearch requires very little configuration, there are a number of
|
||||
settings which need to be configured manually and should definitely be
|
||||
configured before going into production.
|
||||
|
||||
* <<path-settings,`path.data` and `path.logs`>>
|
||||
* <<cluster.name,`cluster.name`>>
|
||||
* <<node.name,`node.name`>>
|
||||
* <<bootstrap.mlockall,`bootstrap.mlockall`>>
|
||||
* <<network.host,`network.host`>>
|
||||
* <<unicast.hosts,`discovery.zen.ping.unicast.hosts`>>
|
||||
* <<minimum_master_nodes,`discovery.zen.minimum_master_nodes`>>
|
||||
* <<node.max_local_storage_nodes,`node.max_local_storage_nodes`>>
|
||||
|
||||
[float]
|
||||
[[path-settings]]
|
||||
=== `path.data` and `path.logs`
|
||||
|
||||
If you are using the `.zip` or `.tar.gz` archives, the `data` and `logs`
|
||||
directories are sub-folders of `$ES_HOME`. If these important folders are
|
||||
left in their default locations, there is a high risk of them being deleted
|
||||
while upgrading Elasticsearch to a new version.
|
||||
|
||||
In production use, you will almost certainly want to change the locations of
|
||||
the data and log folder:
|
||||
|
||||
[source,yaml]
|
||||
--------------------------------------------------
|
||||
path:
|
||||
logs: /var/log/elasticsearch
|
||||
data: /var/data/elasticsearch
|
||||
--------------------------------------------------
|
||||
|
||||
The RPM and Debian distributions already use custom paths for `data` and
|
||||
`logs`.
|
||||
|
||||
The `path.data` settings can be set to multiple paths, in which case all paths
|
||||
will be used to store data (although the files belonging to a single shard
|
||||
will all be stored on the same data path):
|
||||
|
||||
[source,yaml]
|
||||
--------------------------------------------------
|
||||
path:
|
||||
data:
|
||||
- /mnt/elasticsearch_1
|
||||
- /mnt/elasticsearch_2
|
||||
- /mnt/elasticsearch_3
|
||||
--------------------------------------------------
|
||||
|
||||
[float]
|
||||
[[cluster.name]]
|
||||
=== `cluster.name`
|
||||
|
||||
A node can only join a cluster when it shares its `cluster.name` with all the
|
||||
other nodes in the cluster. The default name is `elasticsearch`, but you
|
||||
should change it to an appropriate name which describes the purpose of the
|
||||
cluster.
|
||||
|
||||
[source,yaml]
|
||||
--------------------------------------------------
|
||||
cluster.name: logging-prod
|
||||
--------------------------------------------------
|
||||
|
||||
Make sure that you don't reuse the same cluster names in different
|
||||
environments, otherwise you might end up with nodes joining the wrong cluster.
|
||||
|
||||
[float]
|
||||
[[node.name]]
|
||||
=== `node.name`
|
||||
|
||||
By default, Elasticsearch will randomly pick a descriptive `node.name` from a
|
||||
list of around 3000 Marvel characters when your node starts up, but this also
|
||||
means that the `node.name` will change the next time the node restarts.
|
||||
|
||||
It is worth configuring a more meaningful name which will also have the
|
||||
advantage of persisting after restarting the node:
|
||||
|
||||
[source,yaml]
|
||||
--------------------------------------------------
|
||||
node.name: prod-data-2
|
||||
--------------------------------------------------
|
||||
|
||||
The `node.name` can also be set to the server's HOSTNAME as follows:
|
||||
|
||||
[source,yaml]
|
||||
--------------------------------------------------
|
||||
node.name: ${HOSTNAME}
|
||||
--------------------------------------------------
|
||||
|
||||
[float]
|
||||
[[bootstrap.mlockall]]
|
||||
=== `bootstrap.mlockall`
|
||||
|
||||
It is vitally important to the health of your node that none of the JVM is
|
||||
ever swapped out to disk. One way of achieving that is set the
|
||||
`bootstrap.mlockall` setting to `true`.
|
||||
|
||||
For this setting to have effect, other system settings need to be configured
|
||||
first. See <<mlockall>> for more details about how to set up memory locking
|
||||
correctly.
|
||||
|
||||
[float]
|
||||
[[network.host]]
|
||||
=== `network.host`
|
||||
|
||||
By default, Elasticsearch binds to loopback addresses only -- e.g. `127.0.0.1`
|
||||
and `[::1]`. This is sufficient to run a single development node on a server.
|
||||
|
||||
TIP: In fact, more than one node can be started from the same `$ES_HOME` location
|
||||
on a single node. This can be useful for testing Elasticsearch's ability to
|
||||
form clusters, but it is not a configuration recommended for production.
|
||||
|
||||
In order to communicate and to form a cluster with nodes on other servers,
|
||||
your node will need to bind to a non-loopback address. While there are many
|
||||
<<modules-network,network settings>>, usually all you need to configure is
|
||||
`network.host`:
|
||||
|
||||
[source,yaml]
|
||||
--------------------------------------------------
|
||||
network.host: 192.168.1.10
|
||||
--------------------------------------------------
|
||||
|
||||
The `network.host` setting also understands some special values such as
|
||||
`_local_`, `_site_`, `_global_` and modifiers like `:ip4` and `:ip6`, details
|
||||
of which can be found in <<network-interface-values>>.
|
||||
|
||||
IMPORTANT: As soon you provide a custom setting for `network.host`,
|
||||
Elasticsearch assumes that you are moving from development mode to production
|
||||
mode, and upgrades a number of system startup checks from warnings to
|
||||
exceptions. See <<dev-vs-prod>> for more information.
|
||||
|
||||
[float]
|
||||
[[unicast.hosts]]
|
||||
=== `discovery.zen.ping.unicast.hosts`
|
||||
|
||||
Out of the box, without any network configuration, Elasticsearch will bind to
|
||||
the available loopback addresses and will scan ports 9300 to 9305 to try to
|
||||
connect to other nodes running on the same server. This provides an auto-
|
||||
clustering experience without having to do any configuration.
|
||||
|
||||
When the moment comes to form a cluster with nodes on other servers, you have
|
||||
to provide a seed list of other nodes in the cluster that are likely to be
|
||||
live and contactable. This can be specified as follows:
|
||||
|
||||
[source,yaml]
|
||||
--------------------------------------------------
|
||||
discovery.zen.ping.unicast.hosts:
|
||||
- 192.168.1.10:9300
|
||||
- 192.168.1.11 <1>
|
||||
- seeds.mydomain.com <2>
|
||||
--------------------------------------------------
|
||||
<1> The port will default to 9300 if not specified.
|
||||
<2> A hostname that resolves to multiple IP addresses will try all resolved addresses.
|
||||
|
||||
[float]
|
||||
[[minimum_master_nodes]]
|
||||
=== `discovery.zen.minimum_master_nodes`
|
||||
|
||||
To prevent data loss, it is vital to configure the
|
||||
`discovery.zen.minimum_master_nodes setting` so that each master-eligible node
|
||||
knows the _minimum number of master-eligible nodes_ that must be visible in
|
||||
order to form a cluster.
|
||||
|
||||
Without this setting, a cluster that suffers a network failure is at risk of
|
||||
having the cluster split into two independent clusters -- a split brain --
|
||||
which will lead to data loss. A more detailed explanation is provided
|
||||
in <<split-brain>>.
|
||||
|
||||
|
||||
To avoid a split brain, this setting should be set to a _quorum_ of master-
|
||||
eligible nodes:
|
||||
|
||||
(master_eligible_nodes / 2) + 1
|
||||
|
||||
In other words, if there are three master-eligible nodes, then minimum master
|
||||
nodes should be set to `(3 / 2) + 1` or `2`:
|
||||
|
||||
[source,yaml]
|
||||
--------------------------------------------------
|
||||
discovery.zen.minimum_master_nodes: 2
|
||||
--------------------------------------------------
|
||||
|
||||
IMPORTANT: If `discovery.zen.minimum_master_nodes` is not set when
|
||||
Elasticsearch is running in <<dev-vs-prod,production mode>>, an exception will
|
||||
be thrown which will prevent the node from starting.
|
||||
|
||||
[float]
|
||||
[[node.max_local_storage_nodes]]
|
||||
=== `node.max_local_storage_nodes`
|
||||
|
||||
It is possible to start more than one node on the same server from the same
|
||||
`$ES_HOME`, just by doing the following:
|
||||
|
||||
[source,sh]
|
||||
--------------------------------------------------
|
||||
./bin/elasticsearch -d
|
||||
./bin/elasticsearch -d
|
||||
--------------------------------------------------
|
||||
|
||||
This works just fine: the data directory structure is designed to let multiple
|
||||
nodes coexist. However, a single instance of Elasticsearch is able to use all
|
||||
of the resources of a single server and it seldom makes sense to run multiple
|
||||
nodes on the same server in production.
|
||||
|
||||
It is, however, possible to start more than one node on the same server by
|
||||
mistake and to be completely unaware that this problem exists. To prevent more
|
||||
than one node from sharing the same data directory, it is advisable to add the
|
||||
following setting:
|
||||
|
||||
[source,yaml]
|
||||
--------------------------------------------------
|
||||
node.max_local_storage_nodes: 1
|
||||
--------------------------------------------------
|
||||
|
|
@ -0,0 +1,50 @@
|
|||
[[install-elasticsearch]]
|
||||
== Installing Elasticsearch
|
||||
|
||||
Elasticsearch is provided in the following package formats:
|
||||
|
||||
[horizontal]
|
||||
`zip`/`tar.gz`::
|
||||
|
||||
The `zip` and `tar.gz` packages are suitable for installation on any system
|
||||
and are the easiest choice for getting started with Elasticsearch.
|
||||
+
|
||||
<<zip-targz>> or <<windows>>
|
||||
|
||||
`deb`::
|
||||
|
||||
The `deb` package is suitable for Debian, Ubuntu, and other Debian-based
|
||||
systems. Debian packages may be downloaded from the Elasticsearch website or
|
||||
from our Debian repository.
|
||||
+
|
||||
<<deb>>
|
||||
|
||||
`rpm`::
|
||||
|
||||
The `rpm` package is suitable for installation on Red Hat, Centos, SLES,
|
||||
OpenSuSE and other RPM-based systems. RPMs may be downloaded from the
|
||||
Elasticsearch website or from our RPM repository.
|
||||
+
|
||||
<<rpm>>
|
||||
|
||||
[float]
|
||||
[[config-mgmt-tools]]
|
||||
=== Configuration Management Tools
|
||||
|
||||
We also provide the following configuration management tools to help with
|
||||
large deployments:
|
||||
|
||||
[horizontal]
|
||||
Puppet:: https://github.com/elastic/puppet-elasticsearch[puppet-elasticsearch]
|
||||
Chef:: https://github.com/elastic/cookbook-elasticsearch[cookbook-elasticsearch]
|
||||
|
||||
|
||||
include::install/zip-targz.asciidoc[]
|
||||
|
||||
include::install/deb.asciidoc[]
|
||||
|
||||
include::install/rpm.asciidoc[]
|
||||
|
||||
include::install/windows.asciidoc[]
|
||||
|
||||
|
|
@ -0,0 +1,28 @@
|
|||
==== Checking that Elasticsearch is running
|
||||
|
||||
You can test that your Elasticsearch node is running by sending an HTTP
|
||||
request to port `9200` on `localhost`:
|
||||
|
||||
[source,sh]
|
||||
--------------------------------------------
|
||||
curl locahost:9200
|
||||
--------------------------------------------
|
||||
|
||||
which should give you a response something like this:
|
||||
|
||||
[source,js]
|
||||
--------------------------------------------
|
||||
{
|
||||
"name" : "Harry Leland",
|
||||
"cluster_name" : "elasticsearch",
|
||||
"version" : {
|
||||
"number" : "5.0.0-alpha1",
|
||||
"build_hash" : "f27399d",
|
||||
"build_date" : "2016-03-30T09:51:41.449Z",
|
||||
"build_snapshot" : false,
|
||||
"lucene_version" : "6.0.0"
|
||||
},
|
||||
"tagline" : "You Know, for Search"
|
||||
}
|
||||
--------------------------------------------
|
||||
|
|
@ -0,0 +1,191 @@
|
|||
[[deb]]
|
||||
=== Install Elasticsearch with Debian Package
|
||||
|
||||
The Debian package for Elasticsearch can be <<install-rpm,downloaded from our website>>
|
||||
or from our <<deb-repo,APT repository>>. It can be used to install
|
||||
Elasticsearch on any Debian-based system such as Debian and Ubuntu.
|
||||
|
||||
The latest stable version of Elasticsearch can be found on the
|
||||
link:/downloads/elasticsearch[Download Elasticsearch] page. Other versions can
|
||||
be found on the link:/downloads/past-releases[Past Releases page].
|
||||
|
||||
[[deb-key]]
|
||||
==== Import the Elasticsearch PGP Key
|
||||
|
||||
include::key.asciidoc[]
|
||||
|
||||
[source,sh]
|
||||
-------------------------
|
||||
wget -qO - https://packages.elastic.co/GPG-KEY-elasticsearch | sudo apt-key add -
|
||||
-------------------------
|
||||
|
||||
[[deb-repo]]
|
||||
==== Installing from the APT repository
|
||||
|
||||
You may need to install the `apt-transport-https` package on Debian before proceeding:
|
||||
|
||||
[source,sh]
|
||||
--------------------------------------------------
|
||||
sudo apt-get install apt-transport-https
|
||||
--------------------------------------------------
|
||||
|
||||
Save the repository definition to +/etc/apt/sources.list.d/elasticsearch-{major-version}.list+:
|
||||
|
||||
["source","sh",subs="attributes,callouts"]
|
||||
--------------------------------------------------
|
||||
echo "deb http://packages.elastic.co/elasticsearch/{major-version}/debian stable main" | sudo tee -a /etc/apt/sources.list.d/elasticsearch-{major-version}.list
|
||||
--------------------------------------------------
|
||||
|
||||
[WARNING]
|
||||
==================================================
|
||||
|
||||
Do not use `add-apt-repository` as it will add a `deb-src` entry as well, but
|
||||
we do not provide a source package. If you have added the `deb-src` entry, you
|
||||
will see an error like the following:
|
||||
|
||||
Unable to find expected entry 'main/source/Sources' in Release file
|
||||
(Wrong sources.list entry or malformed file)
|
||||
|
||||
Delete the `deb-src` entry from the `/etc/apt/sources.list` file and the
|
||||
installation should work as expected.
|
||||
==================================================
|
||||
|
||||
You can install the Elasticsearch Debian package with:
|
||||
|
||||
[source,sh]
|
||||
--------------------------------------------------
|
||||
sudo apt-get update && sudo apt-get install elasticsearch
|
||||
--------------------------------------------------
|
||||
|
||||
[WARNING]
|
||||
==================================================
|
||||
If two entries exist for the same Elasticsearch repository, you will see an error like this during `apt-get update`:
|
||||
|
||||
["literal",subs="attributes,callouts"]
|
||||
|
||||
Duplicate sources.list entry http://packages.elastic.co/elasticsearch/{major-version}/debian/ ...`
|
||||
|
||||
Examine +/etc/apt/sources.list.d/elasticsearch-{major-version}.list+ for the duplicate entry or locate the duplicate entry amongst the files in `/etc/apt/sources.list.d/` and the `/etc/apt/sources.list` file.
|
||||
==================================================
|
||||
|
||||
|
||||
[[install-deb]]
|
||||
==== Download and install the Debian package manually
|
||||
|
||||
The Debian package for Elastisearch v{version} can be downloaded from the website and installed as follows:
|
||||
|
||||
["source","sh",subs="attributes"]
|
||||
--------------------------------------------
|
||||
wget https://download.elastic.co/elasticsearch/release/org/elasticsearch/distribution/deb/elasticsearch/{version}/elasticsearch-{version}.deb
|
||||
sha1sum elasticsearch-{version}.deb <1>
|
||||
sudo dpkg -i elasticsearch-{version}.deb
|
||||
--------------------------------------------
|
||||
<1> Compare the SHA produced by `sha1sum` or `shasum` with the
|
||||
https://download.elastics.co/elasticsearch/release/org/elasticsearch/distribution/deb/elasticsearch/{version}/elasticsearch-{version}.deb.sha1[published SHA].
|
||||
|
||||
include::init-systemd.asciidoc[]
|
||||
|
||||
[[deb-running-init]]
|
||||
==== Running Elasticsearch with SysV `init`
|
||||
|
||||
Use the `update-rc.d` command to configure Elasticsearch to start automatically
|
||||
when the system boots up:
|
||||
|
||||
[source,sh]
|
||||
--------------------------------------------------
|
||||
sudo update-rc.d elasticsearch defaults 95 10
|
||||
--------------------------------------------------
|
||||
|
||||
Elasticsearch can be started and stopped using the `service` command:
|
||||
|
||||
[source,sh]
|
||||
--------------------------------------------
|
||||
sudo -i service elasticsearch start
|
||||
sudo -i service elasticsearch stop
|
||||
--------------------------------------------
|
||||
|
||||
If Elasticsearch fails to start for any reason, it will print the reason for
|
||||
failure to STDOUT. Log files can be found in `/var/log/elasticsearch/`.
|
||||
|
||||
[[deb-running-systemd]]
|
||||
include::systemd.asciidoc[]
|
||||
|
||||
[[deb-check-running]]
|
||||
include::check-running.asciidoc[]
|
||||
|
||||
[[deb-configuring]]
|
||||
==== Configuring Elasticsearch
|
||||
|
||||
Elasticsearch loads its configuration from the `/etc/elasticsearch/elasticsearch.yml`
|
||||
file by default. The format of this config file is explained in
|
||||
<<settings>>.
|
||||
|
||||
The Debian package also has a system configuration file (`/etc/default/elasticsearch`),
|
||||
which allows you to set the following parameters:
|
||||
|
||||
include::sysconfig-file.asciidoc[]
|
||||
|
||||
NOTE: Distributions that use `systemd` require that system resource limits be
|
||||
configured via `systemd` rather than via the `/etc/sysconfig/elasticsearch`
|
||||
file. See <<systemd>> for more information.
|
||||
|
||||
[[deb-layout]]
|
||||
==== Directory layout of Debian package
|
||||
|
||||
The Debian package places config files, logs, and the data directory in the appropriate
|
||||
locations for a Debian-based system:
|
||||
|
||||
|
||||
[cols="<h,<,<m,<m",options="header",]
|
||||
|=======================================================================
|
||||
| Type | Description | Default Location | Setting
|
||||
| home
|
||||
| Elasticsearch home directory or `$ES_HOME`
|
||||
| /usr/share/elasticsearch
|
||||
d|
|
||||
|
||||
| bin
|
||||
| Binary scripts including `elasticsearch` to start a node
|
||||
and `elasticsearch-plugin` to install plugins
|
||||
| /usr/share/elasticsearch/bin
|
||||
d|
|
||||
|
||||
| conf
|
||||
| Configuration files including `elasticsearch.yml`
|
||||
| /etc/elasticsearch
|
||||
| path.conf
|
||||
|
||||
| conf
|
||||
| Environment variables including heap size, file descriptors.
|
||||
| /etc/default/elasticsearch
|
||||
d|
|
||||
|
||||
| data
|
||||
| The location of the data files of each index / shard allocated
|
||||
on the node. Can hold multiple locations.
|
||||
| /var/lib/elasticsearch
|
||||
| path.data
|
||||
|
||||
| logs
|
||||
| Log files location.
|
||||
| /var/logs/elasticsearch
|
||||
| path.logs
|
||||
|
||||
| plugins
|
||||
| Plugin files location. Each plugin will be contained in a subdirectory.
|
||||
| /usr/share/elasticsearch/plugins
|
||||
| path.plugins
|
||||
|
||||
| repo
|
||||
| Shared file system repository locations. Can hold multiple locations. A file system repository can be placed in to any subdirectory of any directory specified here.
|
||||
d| Not configured
|
||||
| path.repo
|
||||
|
||||
| script
|
||||
| Location of script files.
|
||||
| /etc/elasticsearch/scripts
|
||||
| path.script
|
||||
|
||||
|=======================================================================
|
||||
|
||||
include::next-steps.asciidoc[]
|
|
@ -0,0 +1,12 @@
|
|||
==== SysV `init` vs `systemd`
|
||||
|
||||
Elasticsearch is not started automatically after installation. How to start
|
||||
and stop Elasticsearch depends on whether your sytem uses SysV `init` or
|
||||
`systemd` (used by newer distributions). You can tell which is being used by
|
||||
running this command:
|
||||
|
||||
[source,sh]
|
||||
--------------------------------------------
|
||||
ps -p 1
|
||||
--------------------------------------------
|
||||
|
|
@ -0,0 +1,8 @@
|
|||
We sign all of our packages with the Elasticsearch Signing Key (PGP key
|
||||
https://pgp.mit.edu/pks/lookup?op=vindex&search=0xD27D666CD88E42B4[D88E42B4],
|
||||
available from https://pgp.mit.edu) with fingerprint:
|
||||
|
||||
4609 5ACC 8548 582C 1A26 99A9 D27D 666C D88E 42B4
|
||||
|
||||
Download and install the public signing key:
|
||||
|
|
@ -0,0 +1,11 @@
|
|||
[role="exclude"]
|
||||
==== Next steps
|
||||
|
||||
You now have a test Elasticsearch environment set up. Before you start
|
||||
serious development or go into production with Elasticsearch, you will need to
|
||||
do some additional setup:
|
||||
|
||||
* Learn how to <<settings,configure Elasticsearch>>.
|
||||
* Configure <<important-settings,important Elasticsearch settings>>.
|
||||
* Configure <<system-config,important system settings>>.
|
||||
|
|
@ -0,0 +1,182 @@
|
|||
[[rpm]]
|
||||
=== Install Elasticsearch with RPM
|
||||
|
||||
The RPM for Elasticsearch can be <<install-rpm,downloaded from our website>>
|
||||
or from our <<rpm-repo,RPM repository>>. It can be used to install
|
||||
Elasticsearch on any RPM-based system such as OpenSuSE, SLES, Centos, Red Hat,
|
||||
and Oracle Enterprise.
|
||||
|
||||
The latest stable version of Elasticsearch can be found on the
|
||||
link:/downloads/elasticsearch[Download Elasticsearch] page. Other versions can
|
||||
be found on the link:/downloads/past-releases[Past Releases page].
|
||||
|
||||
[[rpm-key]]
|
||||
==== Import the Elasticsearch PGP Key
|
||||
|
||||
include::key.asciidoc[]
|
||||
|
||||
[source,sh]
|
||||
-------------------------
|
||||
rpm --import https://packages.elastic.co/GPG-KEY-elasticsearch
|
||||
-------------------------
|
||||
|
||||
If using an older version of RPM, you may need to do this in two steps:
|
||||
|
||||
[source,sh]
|
||||
-------------------------
|
||||
curl https://packages.elastic.co/GPG-KEY-elasticsearch > elasticsearch.asc
|
||||
rpm --import elasticsearch.asc
|
||||
-------------------------
|
||||
|
||||
[[rpm-repo]]
|
||||
==== Installing from the RPM repository
|
||||
|
||||
Create a file called `elasticsearch.repo` in the `/etc/yum.repos.d/` directory
|
||||
for RedHat based distributions, or in the `/etc/zypp/repos.d/` directory for
|
||||
OpenSuSE based distributions, containing:
|
||||
|
||||
["source","sh",subs="attributes,callouts"]
|
||||
--------------------------------------------------
|
||||
[elasticsearch-{major-version}]
|
||||
name=Elasticsearch repository for {major-version} packages
|
||||
baseurl=https://packages.elastic.co/elasticsearch/{major-version}/centos
|
||||
gpgcheck=1
|
||||
gpgkey=https://packages.elastic.co/GPG-KEY-elasticsearch
|
||||
enabled=1
|
||||
autorefresh=1
|
||||
type=rpm-md
|
||||
--------------------------------------------------
|
||||
|
||||
And your repository is ready for use. You can now install Elasticsearch with one of the following commands:
|
||||
|
||||
[source,sh]
|
||||
--------------------------------------------------
|
||||
sudo yum install elasticsearch <1>
|
||||
sudo dnf install elasticsearch <2>
|
||||
sudo zypper install elasticsearch <3>
|
||||
--------------------------------------------------
|
||||
<1> Use `yum` on Centos and older Red Hat distributions.
|
||||
<2> Use `dnf` on newer Red Hat distributions.
|
||||
<3> Use `zypper` on OpenSuSe based distributions
|
||||
|
||||
[[install-rpm]]
|
||||
==== Download and install the RPM manually
|
||||
|
||||
The RPM for Elastisearch v{version} can be downloaded from the website and installed as follows:
|
||||
|
||||
["source","sh",subs="attributes"]
|
||||
--------------------------------------------
|
||||
wget https://download.elastic.co/elasticsearch/release/org/elasticsearch/distribution/rpm/elasticsearch/{version}/elasticsearch-{version}.rpm
|
||||
sha1sum elasticsearch-{version}.rpm <1>
|
||||
sudo rpm --install elasticsearch-{version}.rpm
|
||||
--------------------------------------------
|
||||
<1> Compare the SHA produced by `sha1sum` or `shasum` with the
|
||||
https://download.elastics.co/elasticsearch/release/org/elasticsearch/distribution/rpm/elasticsearch/{version}/elasticsearch-{version}.rpm.sha1[published SHA].
|
||||
|
||||
include::init-systemd.asciidoc[]
|
||||
|
||||
[[rpm-running-init]]
|
||||
==== Running Elasticsearch with SysV `init`
|
||||
|
||||
Use the `chkconfig` command to configure Elasticsearch to start automatically
|
||||
when the system boots up:
|
||||
|
||||
[source,sh]
|
||||
--------------------------------------------------
|
||||
sudo chkconfig --add elasticsearch
|
||||
--------------------------------------------------
|
||||
|
||||
Elasticsearch can be started and stopped using the `service` command:
|
||||
|
||||
[source,sh]
|
||||
--------------------------------------------
|
||||
sudo -i service elasticsearch start
|
||||
sudo -i service elasticsearch stop
|
||||
--------------------------------------------
|
||||
|
||||
If Elasticsearch fails to start for any reason, it will print the reason for
|
||||
failure to STDOUT. Log files can be found in `/var/log/elasticsearch/`.
|
||||
|
||||
|
||||
[[rpm-running-systemd]]
|
||||
include::systemd.asciidoc[]
|
||||
|
||||
[[rpm-check-running]]
|
||||
include::check-running.asciidoc[]
|
||||
|
||||
[[rpm-configuring]]
|
||||
==== Configuring Elasticsearch
|
||||
|
||||
Elasticsearch loads its configuration from the `/etc/elasticsearch/elasticsearch.yml`
|
||||
file by default. The format of this config file is explained in
|
||||
<<settings>>.
|
||||
|
||||
The RPM also has a system configuration file (`/etc/sysconfig/elasticsearch`),
|
||||
which allows you to set the following parameters:
|
||||
|
||||
include::sysconfig-file.asciidoc[]
|
||||
|
||||
NOTE: Distributions that use `systemd` require that system resource limits be
|
||||
configured via `systemd` rather than via the `/etc/sysconfig/elasticsearch`
|
||||
file. See <<systemd>> for more information.
|
||||
|
||||
[[rpm-layout]]
|
||||
==== Directory layout of RPM
|
||||
|
||||
The RPM places config files, logs, and the data directory in the appropriate
|
||||
locations for an RPM-based system:
|
||||
|
||||
|
||||
[cols="<h,<,<m,<m",options="header",]
|
||||
|=======================================================================
|
||||
| Type | Description | Default Location | Setting
|
||||
| home
|
||||
| Elasticsearch home directory or `$ES_HOME`
|
||||
| /usr/share/elasticsearch
|
||||
d|
|
||||
|
||||
| bin
|
||||
| Binary scripts including `elasticsearch` to start a node
|
||||
and `elasticsearch-plugin` to install plugins
|
||||
| /usr/share/elasticsearch/bin
|
||||
d|
|
||||
|
||||
| conf
|
||||
| Configuration files including `elasticsearch.yml`
|
||||
| /etc/elasticsearch
|
||||
| path.conf
|
||||
|
||||
| conf
|
||||
| Environment variables including heap size, file descriptors.
|
||||
| /etc/sysconfig/elasticsearch
|
||||
d|
|
||||
|
||||
| data
|
||||
| The location of the data files of each index / shard allocated
|
||||
on the node. Can hold multiple locations.
|
||||
| /var/lib/elasticsearch
|
||||
| path.data
|
||||
|
||||
| logs
|
||||
| Log files location.
|
||||
| /var/logs/elasticsearch
|
||||
| path.logs
|
||||
|
||||
| plugins
|
||||
| Plugin files location. Each plugin will be contained in a subdirectory.
|
||||
| /usr/share/elasticsearch/plugins
|
||||
| path.plugins
|
||||
|
||||
| repo
|
||||
| Shared file system repository locations. Can hold multiple locations. A file system repository can be placed in to any subdirectory of any directory specified here.
|
||||
d| Not configured
|
||||
| path.repo
|
||||
|
||||
| script
|
||||
| Location of script files.
|
||||
| /etc/elasticsearch/scripts
|
||||
| path.script
|
||||
|
||||
|=======================================================================
|
||||
|
||||
include::next-steps.asciidoc[]
|
|
@ -0,0 +1,71 @@
|
|||
[horizontal]
|
||||
`ES_USER`::
|
||||
|
||||
The user to run as, defaults to `elasticsearch`.
|
||||
|
||||
`ES_GROUP`::
|
||||
|
||||
The group to run as, defaults to `elasticsearch`.
|
||||
|
||||
`ES_HEAP_SIZE`::
|
||||
|
||||
The heap size to start with.
|
||||
|
||||
`ES_HEAP_NEWSIZE`::
|
||||
|
||||
The size of the new generation heap.
|
||||
|
||||
`ES_DIRECT_SIZE`::
|
||||
|
||||
The maximum size of the direct memory.
|
||||
|
||||
`MAX_OPEN_FILES`::
|
||||
|
||||
Maximum number of open files, defaults to `65536`.
|
||||
|
||||
`MAX_LOCKED_MEMORY`::
|
||||
|
||||
Maximum locked memory size. Set to `unlimited if you use the
|
||||
`bootstrap.mlockall` option in elasticsearch.yml. You must also set
|
||||
ES_HEAP_SIZE.
|
||||
|
||||
`MAX_MAP_COUNT`::
|
||||
|
||||
Maximum number of memory map areas a process may have. If you use `mmapfs`
|
||||
as index store type, make sure this is set to a high value. For more
|
||||
information, check the
|
||||
https://github.com/torvalds/linux/blob/master/Documentation/sysctl/vm.txt[linux kernel documentation]
|
||||
about `max_map_count`. This is set via `sysctl` before starting
|
||||
elasticsearch. Defaults to `262144`.
|
||||
|
||||
`LOG_DIR`::
|
||||
|
||||
Log directory, defaults to `/var/log/elasticsearch`.
|
||||
|
||||
`DATA_DIR`::
|
||||
|
||||
Data directory, defaults to `/var/lib/elasticsearch`.
|
||||
|
||||
`CONF_DIR`::
|
||||
|
||||
Configuration file directory (which needs to include `elasticsearch.yml`
|
||||
and `logging.yml` files), defaults to `/etc/elasticsearch`.
|
||||
|
||||
`ES_JAVA_OPTS`::
|
||||
|
||||
Any additional JVM system properties you may want to apply.
|
||||
|
||||
`RESTART_ON_UPGRADE`::
|
||||
|
||||
Configure restart on package upgrade, defaults to `false`. This means you
|
||||
will have to restart your elasticsearch instance after installing a
|
||||
package manually. The reason for this is to ensure, that upgrades in a
|
||||
cluster do not result in a continuous shard reallocation resulting in high
|
||||
network traffic and reducing the response times of your cluster.
|
||||
|
||||
`ES_GC_LOG_FILE` ::
|
||||
|
||||
The absolute log file path for creating a garbage collection logfile,
|
||||
which is done by the JVM. Note that this logfile can grow pretty quick and
|
||||
thus is disabled by default.
|
||||
|
|
@ -0,0 +1,30 @@
|
|||
==== Running Elasticsearch with `systemd`
|
||||
|
||||
To configure Elasticsearch to start automatically when the system boots up,
|
||||
run the following commands:
|
||||
|
||||
[source,sh]
|
||||
--------------------------------------------------
|
||||
sudo /bin/systemctl daemon-reload
|
||||
sudo /bin/systemctl enable elasticsearch.service
|
||||
--------------------------------------------------
|
||||
|
||||
Elasticsearch can be started and stopped as follows:
|
||||
|
||||
[source,sh]
|
||||
--------------------------------------------
|
||||
sudo systemctl start elasticsearch.service
|
||||
sudo systemctl stop elasticsearch.service
|
||||
--------------------------------------------
|
||||
|
||||
These commands provide no feedback as to whether Elasticsearch was started
|
||||
successfully or not. Instead, this information will be written to the
|
||||
`systemd` journal, which can be tailed as follows:
|
||||
|
||||
[source,sh]
|
||||
--------------------------------------------
|
||||
sudo journalctl -f
|
||||
--------------------------------------------
|
||||
|
||||
Log files can be found in `/var/log/elasticsearch/`.
|
||||
|
|
@ -0,0 +1,174 @@
|
|||
[[windows]]
|
||||
=== Install Elasticsearch on Windows
|
||||
|
||||
Elasticsearch can be installed on Windows using the `.zip` package. This
|
||||
comes with a `service.bat` command which will setup Elasticsearch to run as a
|
||||
service.
|
||||
|
||||
The latest stable version of Elasticsearch can be found on the
|
||||
link:/downloads/elasticsearch[Download Elasticsearch] page.
|
||||
Other versions can be found on the
|
||||
link:/downloads/past-releases[Past Releases page].
|
||||
|
||||
[[install-windows]]
|
||||
==== Download and install the `.zip` package
|
||||
|
||||
Download the `.zip` archive for Elastisearch v{version} from: https://download.elastic.co/elasticsearch/release/org/elasticsearch/distribution/zip/elasticsearch/{version}/elasticsearch-{version}.zip
|
||||
|
||||
Unzip it with your favourite unzip tool. This will create a folder called
|
||||
+elasticsearch-{version}+, which we will refer to as `$ES_HOME`. In a terminal
|
||||
window, `CD` to the `$ES_HOME` directory, for instance:
|
||||
|
||||
["source","sh",subs="attributes"]
|
||||
----------------------------
|
||||
CD c:\elasticsearch-{version}
|
||||
----------------------------
|
||||
|
||||
[[windows-running]]
|
||||
==== Running Elasticsearch from the command line
|
||||
|
||||
Elasticsearch can be started from the command line as follows:
|
||||
|
||||
[source,sh]
|
||||
--------------------------------------------
|
||||
.\bin\elasticsearch
|
||||
--------------------------------------------
|
||||
|
||||
By default, Elasticsearch runs in the foreground, prints its logs to `STDOUT`,
|
||||
and can be stopped by pressing `Ctrl-C`.
|
||||
|
||||
include::check-running.asciidoc[]
|
||||
|
||||
[[windows-service]]
|
||||
==== Installing Elasticsearch as a Service on Windows
|
||||
|
||||
Elasticsearch can be installed as a service to run in the background or start
|
||||
automatically at boot time without any user interaction. This can be achieved
|
||||
through the `service.bat` script in the `bin\` folder which allows one to
|
||||
install, remove, manage or configure the service and potentially start and
|
||||
stop the service, all from the command-line.
|
||||
|
||||
["source","sh",subs="attributes,callouts"]
|
||||
--------------------------------------------------
|
||||
c:\elasticsearch-{version}{backslash}bin>service
|
||||
|
||||
Usage: service.bat install|remove|start|stop|manager [SERVICE_ID]
|
||||
--------------------------------------------------
|
||||
|
||||
The script requires one parameter (the command to execute) followed by an
|
||||
optional one indicating the service id (useful when installing multiple
|
||||
Elasticsearch services).
|
||||
|
||||
The commands available are:
|
||||
|
||||
[horizontal]
|
||||
`install`:: Install Elasticsearch as a service
|
||||
|
||||
`remove`:: Remove the installed Elasticsearch service (and stop the service if started)
|
||||
|
||||
`start`:: Start the Elasticsearch service (if installed)
|
||||
|
||||
`stop`:: Stop the Elasticsearch service (if started)
|
||||
|
||||
`manager`:: Start a GUI for managing the installed service
|
||||
|
||||
Note that the environment configuration options available during the
|
||||
installation are copied and will be used during the service lifecycle. This
|
||||
means any changes made to them after the installation will not be picked up
|
||||
unless the service is reinstalled.
|
||||
|
||||
Based on the architecture of the available JDK/JRE (set through `JAVA_HOME`),
|
||||
the appropriate 64-bit(x64) or 32-bit(x86) service will be installed. This
|
||||
information is made available during install:
|
||||
|
||||
["source","sh",subs="attributes"]
|
||||
--------------------------------------------------
|
||||
c:\elasticsearch-{version}{backslash}bin>service install
|
||||
Installing service : "elasticsearch-service-x64"
|
||||
Using JAVA_HOME (64-bit): "c:\jvm\jdk1.8"
|
||||
The service 'elasticsearch-service-x64' has been installed.
|
||||
--------------------------------------------------
|
||||
|
||||
NOTE: While a JRE can be used for the Elasticsearch service, due to its use of a client VM (as oppose to a server JVM which
|
||||
offers better performance for long-running applications) its usage is discouraged and a warning will be issued.
|
||||
|
||||
[float]
|
||||
=== Customizing service settings
|
||||
|
||||
There are two ways to customize the service settings:
|
||||
|
||||
Manager GUI:: accessible through `manager` command, the GUI offers insight into the installed service including its status, startup type,
|
||||
JVM, start and stop settings among other things. Simply invoking `service.bat` from the command-line with the aforementioned option
|
||||
will open up the manager window:
|
||||
|
||||
image::images/service-manager-win.png["Windows Service Manager GUI",align="center"]
|
||||
|
||||
Customizing `service.bat`:: at its core, `service.bat` relies on http://commons.apache.org/proper/commons-daemon/[Apache Commons Daemon] project
|
||||
to install the services. For full flexibility such as customizing the user under which the service runs, one can modify the installation
|
||||
parameters to tweak all the parameters accordingly. Do note that this requires reinstalling the service for the new settings to be applied.
|
||||
|
||||
NOTE: There is also a community supported customizable MSI installer available: https://github.com/salyh/elasticsearch-msi-installer (by Hendrik Saly).
|
||||
|
||||
[[windows-layout]]
|
||||
==== Directory layout of `.zip` archive
|
||||
|
||||
The `.zip` package is entirely self-contained. All files and directories are,
|
||||
by default, contained within `$ES_HOME` -- the directory created when
|
||||
unpacking the archive.
|
||||
|
||||
This is very convenient because you don't have to create any directories to
|
||||
start using Elasticsearch, and uninstalling Elasticsearch is as easy as
|
||||
removing the `$ES_HOME` directory. However, it is advisable to change the
|
||||
default locations of the config directory, the data directory, and the logs
|
||||
directory so that you do not delete important data later on.
|
||||
|
||||
|
||||
[cols="<h,<,<m,<m",options="header",]
|
||||
|=======================================================================
|
||||
| Type | Description | Default Location | Setting
|
||||
| home
|
||||
| Elasticsearch home directory or `$ES_HOME`
|
||||
d| Directory created by unpacking the archive
|
||||
|
|
||||
|
||||
| bin
|
||||
| Binary scripts including `elasticsearch` to start a node
|
||||
and `elasticsearch-plugin` to install plugins
|
||||
| $ES_HOME\bin
|
||||
d|
|
||||
|
||||
| conf
|
||||
| Configuration files including `elasticsearch.yml`
|
||||
| $ES_HOME\config
|
||||
| path.conf
|
||||
|
||||
| data
|
||||
| The location of the data files of each index / shard allocated
|
||||
on the node. Can hold multiple locations.
|
||||
| $ES_HOME\data
|
||||
| path.data
|
||||
|
||||
| logs
|
||||
| Log files location.
|
||||
| $ES_HOME\logs
|
||||
| path.logs
|
||||
|
||||
| plugins
|
||||
| Plugin files location. Each plugin will be contained in a subdirectory.
|
||||
| $ES_HOME\plugins
|
||||
| path.plugins
|
||||
|
||||
| repo
|
||||
| Shared file system repository locations. Can hold multiple locations. A file system repository can be placed in to any subdirectory of any directory specified here.
|
||||
d| Not configured
|
||||
| path.repo
|
||||
|
||||
| script
|
||||
| Location of script files.
|
||||
| $ES_HOME\scripts
|
||||
| path.script
|
||||
|
||||
|=======================================================================
|
||||
|
||||
|
||||
include::next-steps.asciidoc[]
|
|
@ -0,0 +1,165 @@
|
|||
[[zip-targz]]
|
||||
=== Install Elasticsearch with `.zip` or `.tar.gz`
|
||||
|
||||
Elasticsearch is provided as a `.zip` and as a `.tar.gz` package. These
|
||||
packages can be used to install Elasticsearch on any system and are the
|
||||
easiest package format to use when trying out Elasticsearch.
|
||||
|
||||
The latest stable version of Elasticsearch can be found on the
|
||||
link:/downloads/elasticsearch[Download Elasticsearch] page.
|
||||
Other versions can be found on the
|
||||
link:/downloads/past-releases[Past Releases page].
|
||||
|
||||
[[install-zip]]
|
||||
==== Download and install the `.zip` package
|
||||
|
||||
The `.zip` archive for Elastisearch v{version} can be downloaded and installed as follows:
|
||||
|
||||
["source","sh",subs="attributes"]
|
||||
--------------------------------------------
|
||||
wget https://download.elastic.co/elasticsearch/release/org/elasticsearch/distribution/zip/elasticsearch/{version}/elasticsearch-{version}.zip
|
||||
sha1sum elasticsearch-{version}.zip <1>
|
||||
unzip elasticsearch-{version}.zip
|
||||
cd elasticsearch-{version}/ <2>
|
||||
--------------------------------------------
|
||||
<1> Compare the SHA produced by `sha1sum` or `shasum` with the
|
||||
https://download.elastics.co/elasticsearch/release/org/elasticsearch/distribution/zip/elasticsearch/{version}/elasticsearch-{version}.zip.sha1[published SHA].
|
||||
<2> This directory is known as `$ES_HOME`.
|
||||
|
||||
[[install-targz]]
|
||||
==== Download and install the `.tar.gz` package
|
||||
|
||||
The `.tar.gz` archive for Elastisearch v{version} can be downloaded and installed as follows:
|
||||
|
||||
["source","sh",subs="attributes"]
|
||||
--------------------------------------------
|
||||
wget https://download.elastic.co/elasticsearch/release/org/elasticsearch/distribution/tar/elasticsearch/{version}/elasticsearch-{version}.tar.gz
|
||||
sha1sum elasticsearch-{version}.tar.gz <1>
|
||||
tar -xzf elasticsearch-{version}.tar.gz
|
||||
cd elasticsearch-{version}/ <2>
|
||||
--------------------------------------------
|
||||
<1> Compare the SHA produced by `sha1sum` or `shasum` with the
|
||||
https://download.elastic.co/elasticsearch/release/org/elasticsearch/distribution/tar/elasticsearch/{version}/elasticsearch-{version}.tar.gz.sha1[published SHA].
|
||||
<2> This directory is known as `$ES_HOME`.
|
||||
|
||||
[[zip-targz-running]]
|
||||
==== Running Elasticsearch from the command line
|
||||
|
||||
Elasticsearch can be started from the command line as follows:
|
||||
|
||||
[source,sh]
|
||||
--------------------------------------------
|
||||
./bin/elasticsearch
|
||||
--------------------------------------------
|
||||
|
||||
By default, Elasticsearch runs in the foreground, prints its logs to `STDOUT`,
|
||||
and can be stopped by pressing `Ctrl-C`.
|
||||
|
||||
include::check-running.asciidoc[]
|
||||
|
||||
[[setup-installation-daemon]]
|
||||
==== Running as a daemon
|
||||
|
||||
To run Elasticsearch as a daemon, specify `-d` on the command line, and record
|
||||
the process ID in a file using the `-p` option:
|
||||
|
||||
[source,sh]
|
||||
--------------------------------------------
|
||||
./bin/elasticsearch -d -p pid
|
||||
--------------------------------------------
|
||||
|
||||
Log messages can be found in the `$ES_HOME/logs/` directory.
|
||||
|
||||
To shut down Elasticsearch, kill the process ID recorded in the `pid` file:
|
||||
|
||||
[source,sh]
|
||||
--------------------------------------------
|
||||
kill `cat pid`
|
||||
--------------------------------------------
|
||||
|
||||
NOTE: The startup scripts provided in the <<rpm,RPM>> and <<deb,Debian>>
|
||||
packages take care of starting and stopping the Elasticsearch process for you.
|
||||
|
||||
[[zip-targz-configuring]]
|
||||
==== Configuring Elasticsearch on the command line
|
||||
|
||||
Elasticsearch loads its configuration from the `$ES_HOME/config/elasticsearch.yml`
|
||||
file by default. The format of this config file is explained in
|
||||
<<settings>>.
|
||||
|
||||
Any settings that can be specified in the config file can also be specified on
|
||||
the command line, using the `-E` syntax, and prepending `es.` to the setting
|
||||
name, as follows:
|
||||
|
||||
[source,sh]
|
||||
--------------------------------------------
|
||||
./bin/elasticsearch -d -E es.cluster.name=my_cluster -E es.node.name=node_1
|
||||
--------------------------------------------
|
||||
|
||||
TIP: Typically, any cluster-wide settings (like `cluster.name`) should be
|
||||
added to the `elasticsearch.yml` config file, while any node-specific settings
|
||||
such as `node.name` could be specified on the command line.
|
||||
|
||||
[[zip-targz-layout]]
|
||||
==== Directory layout of `.zip` and `.tar.gz` archives
|
||||
|
||||
The `.zip` and `.tar.gz` packages are entirely self-contained. All files and
|
||||
directories are, by default, contained within `$ES_HOME` -- the directory
|
||||
created when unpacking the archive.
|
||||
|
||||
This is very convenient because you don't have to create any directories to
|
||||
start using Elasticsearch, and uninstalling Elasticsearch is as easy as
|
||||
removing the `$ES_HOME` directory. However, it is advisable to change the
|
||||
default locations of the config directory, the data directory, and the logs
|
||||
directory so that you do not delete important data later on.
|
||||
|
||||
|
||||
[cols="<h,<,<m,<m",options="header",]
|
||||
|=======================================================================
|
||||
| Type | Description | Default Location | Setting
|
||||
| home
|
||||
| Elasticsearch home directory or `$ES_HOME`
|
||||
d| Directory created by unpacking the archive
|
||||
|
|
||||
|
||||
| bin
|
||||
| Binary scripts including `elasticsearch` to start a node
|
||||
and `elasticsearch-plugin` to install plugins
|
||||
| $ES_HOME/bin
|
||||
d|
|
||||
|
||||
| conf
|
||||
| Configuration files including `elasticsearch.yml`
|
||||
| $ES_HOME/config
|
||||
| path.conf
|
||||
|
||||
| data
|
||||
| The location of the data files of each index / shard allocated
|
||||
on the node. Can hold multiple locations.
|
||||
| $ES_HOME/data
|
||||
| path.data
|
||||
|
||||
| logs
|
||||
| Log files location.
|
||||
| $ES_HOME/logs
|
||||
| path.logs
|
||||
|
||||
| plugins
|
||||
| Plugin files location. Each plugin will be contained in a subdirectory.
|
||||
| $ES_HOME/plugins
|
||||
| path.plugins
|
||||
|
||||
| repo
|
||||
| Shared file system repository locations. Can hold multiple locations. A file system repository can be placed in to any subdirectory of any directory specified here.
|
||||
d| Not configured
|
||||
| path.repo
|
||||
|
||||
| script
|
||||
| Location of script files.
|
||||
| $ES_HOME/scripts
|
||||
| path.script
|
||||
|
||||
|=======================================================================
|
||||
|
||||
|
||||
include::next-steps.asciidoc[]
|
|
@ -1,135 +0,0 @@
|
|||
[[setup-repositories]]
|
||||
== Repositories
|
||||
|
||||
We also have repositories available for APT and YUM based distributions. Note that we only provide
|
||||
binary packages, but no source packages, as the packages are created as part of the Elasticsearch
|
||||
build.
|
||||
|
||||
We have split the major versions in separate urls to avoid accidental upgrades across major version.
|
||||
For all 2.x releases use 2.x as version number, for 3.x.y use 3.x etc...
|
||||
|
||||
We use the PGP key https://pgp.mit.edu/pks/lookup?op=vindex&search=0xD27D666CD88E42B4[D88E42B4],
|
||||
Elasticsearch Signing Key, with fingerprint
|
||||
|
||||
4609 5ACC 8548 582C 1A26 99A9 D27D 666C D88E 42B4
|
||||
|
||||
to sign all our packages. It is available from https://pgp.mit.edu.
|
||||
|
||||
[float]
|
||||
=== APT
|
||||
|
||||
Download and install the Public Signing Key:
|
||||
|
||||
[source,sh]
|
||||
--------------------------------------------------
|
||||
wget -qO - https://packages.elastic.co/GPG-KEY-elasticsearch | sudo apt-key add -
|
||||
--------------------------------------------------
|
||||
|
||||
Save the repository definition to +/etc/apt/sources.list.d/elasticsearch-{major-version}.list+:
|
||||
|
||||
["source","sh",subs="attributes,callouts"]
|
||||
--------------------------------------------------
|
||||
echo "deb http://packages.elastic.co/elasticsearch/{major-version}/debian stable main" | sudo tee -a /etc/apt/sources.list.d/elasticsearch-{major-version}.list
|
||||
--------------------------------------------------
|
||||
|
||||
[WARNING]
|
||||
==================================================
|
||||
Use the `echo` method described above to add the Elasticsearch repository. Do not use `add-apt-repository`
|
||||
as it will add a `deb-src` entry as well, but we do not provide a source package.
|
||||
If you have added the `deb-src` entry, you will see an error like
|
||||
the following:
|
||||
|
||||
Unable to find expected entry 'main/source/Sources' in Release file (Wrong sources.list entry or malformed file)
|
||||
|
||||
Just delete the `deb-src` entry from the `/etc/apt/sources.list` file and the installation should work as expected.
|
||||
==================================================
|
||||
|
||||
Run apt-get update and the repository is ready for use. You can install it with:
|
||||
|
||||
[source,sh]
|
||||
--------------------------------------------------
|
||||
sudo apt-get update && sudo apt-get install elasticsearch
|
||||
--------------------------------------------------
|
||||
|
||||
[WARNING]
|
||||
==================================================
|
||||
If two entries exist for the same Elasticsearch repository, you will see an error like this during `apt-get update`:
|
||||
|
||||
["literal",subs="attributes,callouts"]
|
||||
|
||||
Duplicate sources.list entry http://packages.elastic.co/elasticsearch/{major-version}/debian/ ...`
|
||||
|
||||
Examine +/etc/apt/sources.list.d/elasticsearch-{major-version}.list+ for the duplicate entry or locate the duplicate entry amongst the files in `/etc/apt/sources.list.d/` and the `/etc/apt/sources.list` file.
|
||||
==================================================
|
||||
|
||||
Configure Elasticsearch to automatically start during bootup. If your
|
||||
distribution is using SysV init, then you will need to run:
|
||||
|
||||
[source,sh]
|
||||
--------------------------------------------------
|
||||
sudo update-rc.d elasticsearch defaults 95 10
|
||||
--------------------------------------------------
|
||||
|
||||
Otherwise if your distribution is using systemd:
|
||||
|
||||
[source,sh]
|
||||
--------------------------------------------------
|
||||
sudo /bin/systemctl daemon-reload
|
||||
sudo /bin/systemctl enable elasticsearch.service
|
||||
--------------------------------------------------
|
||||
|
||||
[float]
|
||||
=== YUM / DNF
|
||||
|
||||
Download and install the public signing key:
|
||||
|
||||
[source,sh]
|
||||
--------------------------------------------------
|
||||
rpm --import https://packages.elastic.co/GPG-KEY-elasticsearch
|
||||
--------------------------------------------------
|
||||
|
||||
Add the following in your `/etc/yum.repos.d/` directory
|
||||
in a file with a `.repo` suffix, for example `elasticsearch.repo`
|
||||
|
||||
["source","sh",subs="attributes,callouts"]
|
||||
--------------------------------------------------
|
||||
[elasticsearch-{major-version}]
|
||||
name=Elasticsearch repository for {major-version} packages
|
||||
baseurl=https://packages.elastic.co/elasticsearch/{major-version}/centos
|
||||
gpgcheck=1
|
||||
gpgkey=https://packages.elastic.co/GPG-KEY-elasticsearch
|
||||
enabled=1
|
||||
--------------------------------------------------
|
||||
|
||||
And your repository is ready for use. You can install it with:
|
||||
|
||||
[source,sh]
|
||||
--------------------------------------------------
|
||||
yum install elasticsearch
|
||||
--------------------------------------------------
|
||||
|
||||
Or, for newer versions of Fedora and Redhat:
|
||||
|
||||
[source,sh]
|
||||
--------------------------------------------------
|
||||
dnf install elasticsearch
|
||||
--------------------------------------------------
|
||||
|
||||
Configure Elasticsearch to automatically start during bootup. If your
|
||||
distribution is using SysV `init` (check with `ps -p 1`), then you will need to run:
|
||||
|
||||
WARNING: The repositories do not work with older rpm based distributions
|
||||
that still use RPM v3, like CentOS5.
|
||||
|
||||
[source,sh]
|
||||
--------------------------------------------------
|
||||
chkconfig --add elasticsearch
|
||||
--------------------------------------------------
|
||||
|
||||
Otherwise if your distribution is using `systemd`:
|
||||
|
||||
[source,sh]
|
||||
--------------------------------------------------
|
||||
sudo /bin/systemctl daemon-reload
|
||||
sudo /bin/systemctl enable elasticsearch.service
|
||||
--------------------------------------------------
|
|
@ -14,10 +14,10 @@ To perform a rolling upgrade:
|
|||
|
||||
==== Step 1: Disable shard allocation
|
||||
|
||||
When you shut down a node, the allocation process will immediately try to
|
||||
replicate the shards that were on that node to other nodes in the cluster,
|
||||
causing a lot of wasted I/O. This can be avoided by disabling allocation
|
||||
before shutting down a node:
|
||||
When you shut down a node, the allocation process will wait for one minute
|
||||
before starting to replicate the shards that were on that node to other nodes
|
||||
in the cluster, causing a lot of wasted I/O. This can be avoided by disabling
|
||||
allocation before shutting down a node:
|
||||
|
||||
[source,js]
|
||||
--------------------------------------------------
|
||||
|
@ -60,15 +60,15 @@ default.
|
|||
|
||||
It is a good idea to place these directories in a different location so that
|
||||
there is no chance of deleting them when upgrading Elasticsearch. These
|
||||
custom paths can be <<paths,configured>> with the `path.conf` and
|
||||
`path.data` settings.
|
||||
custom paths can be <<path-settings,configured>> with the `path.conf`,
|
||||
`path.logs`, and `path.data` settings.
|
||||
|
||||
The Debian and RPM packages place these directories in the
|
||||
<<setup-dir-layout,appropriate place>> for each operating system.
|
||||
The <<deb,Debian>> and <<rpm,RPM>> packages place these directories in the
|
||||
appropriate place for each operating system.
|
||||
|
||||
================================================
|
||||
|
||||
To upgrade using a <<setup-repositories,Debian or RPM>> package:
|
||||
To upgrade using a <<deb,Debian>> or <<rpm,RPM>> package:
|
||||
|
||||
* Use `rpm` or `dpkg` to install the new package. All files should be
|
||||
placed in their proper locations, and config files should not be
|
||||
|
@ -87,7 +87,13 @@ To upgrade using a zip or compressed tarball:
|
|||
to your new installation, or configure the location of the data directory
|
||||
in the `config/elasticsearch.yml` file, with the `path.data` setting.
|
||||
|
||||
==== Step 4: Start the upgraded node
|
||||
==== Step 4: Upgrade any plugins
|
||||
|
||||
Elasticsearch plugins must be upgraded when upgrading a node. Use the
|
||||
`elasticsearch-plugin` script to install the correct version of any plugins
|
||||
that you need.
|
||||
|
||||
==== Step 5: Start the upgraded node
|
||||
|
||||
Start the now upgraded node and confirm that it joins the cluster by checking
|
||||
the log file or by checking the output of this request:
|
||||
|
@ -98,7 +104,7 @@ GET _cat/nodes
|
|||
--------------------------------------------------
|
||||
// AUTOSENSE
|
||||
|
||||
==== Step 5: Reenable shard allocation
|
||||
==== Step 6: Reenable shard allocation
|
||||
|
||||
Once the node has joined the cluster, reenable shard allocation to start using
|
||||
the node:
|
||||
|
@ -114,7 +120,7 @@ PUT /_cluster/settings
|
|||
--------------------------------------------------
|
||||
// AUTOSENSE
|
||||
|
||||
==== Step 6: Wait for the node to recover
|
||||
==== Step 7: Wait for the node to recover
|
||||
|
||||
You should wait for the cluster to finish shard allocation before upgrading
|
||||
the next node. You can check on progress with the <<cat-health,`_cat/health`>>
|
||||
|
@ -162,7 +168,7 @@ GET _cat/recovery
|
|||
If you stopped indexing, then it is safe to resume indexing as soon as
|
||||
recovery has completed.
|
||||
|
||||
==== Step 7: Repeat
|
||||
==== Step 8: Repeat
|
||||
|
||||
When the cluster is stable and the node has recovered, repeat the above steps
|
||||
for all remaining nodes.
|
||||
|
|
|
@ -0,0 +1,45 @@
|
|||
[[system-config]]
|
||||
== Important System Configuration
|
||||
|
||||
Ideally, Elasticsearch should run alone on a server and use all of the
|
||||
resources available to it. In order to do so, you need to configure your
|
||||
operating system to allow the user running Elasticsearch to access more
|
||||
resources than allowed by default.
|
||||
|
||||
The following settings *must* be addressed before going to production:
|
||||
|
||||
* <<heap-size,Set JVM heap size>>
|
||||
* <<setup-configuration-memory,Disable swapping>>
|
||||
* <<file-descriptors,Increase file descriptors>>
|
||||
* <<vm-max-map-count,Ensure sufficient virtual memory>>
|
||||
* <<max-number-of-threads,Ensure sufficient threads>>
|
||||
|
||||
[[dev-vs-prod]]
|
||||
[float]
|
||||
=== Development mode vs production mode
|
||||
|
||||
By default, Elasticsearch assumes that you are working in development mode.
|
||||
If any of the above settings are not configured correctly, a warning will be
|
||||
written to the log file, but you will be able to start and run your
|
||||
Elasticsearch node.
|
||||
|
||||
As soon as you configure a network setting like `network.host`, Elasticsearch
|
||||
assumes that you are moving to production and will upgrade the above warnings
|
||||
to exceptions. These exceptions will prevent your Elasticsearch node from
|
||||
starting. This is an important safety measure to ensure that you will not
|
||||
lose data because of a malconfigured server.
|
||||
|
||||
include::sysconfig/configuring.asciidoc[]
|
||||
|
||||
include::sysconfig/heap_size.asciidoc[]
|
||||
|
||||
include::sysconfig/swap.asciidoc[]
|
||||
|
||||
include::sysconfig/file-descriptors.asciidoc[]
|
||||
|
||||
include::sysconfig/virtual-memory.asciidoc[]
|
||||
|
||||
include::sysconfig/threads.asciidoc[]
|
||||
|
||||
|
||||
|
|
@ -0,0 +1,117 @@
|
|||
[[setting-system-settings]]
|
||||
=== Configuring system settings
|
||||
|
||||
Where to configure systems settings depends on which package you have used to
|
||||
install Elasticsearch, and which operating system you are using.
|
||||
|
||||
When using the `.zip` or `.tar.gz` packages, system settings can be configured:
|
||||
|
||||
* temporarily with <<ulimit,`ulimit`>>, or
|
||||
* permanently in <<limits.conf,`/etc/security/limits.conf`>>.
|
||||
|
||||
When using the RPM or Debian packages, most system settings are set in the
|
||||
<<sysconfig,system configuration file>>. However, systems which use systemd
|
||||
require that system limits are specified in a
|
||||
<<systemd,systemd configuration file>>.
|
||||
|
||||
[[ulimit]]
|
||||
==== `ulimit`
|
||||
|
||||
On Linux systems, `ulimit` can be used to change resource limits on a
|
||||
temporary basis. Limits usually need to be set as `root` before switching to
|
||||
the user that will run Elasticsearch. For example, to set the number of
|
||||
open file handles (`ulimit -n`) to 65,536, you can do the following:
|
||||
|
||||
[source,sh]
|
||||
--------------------------------
|
||||
sudo su <1>
|
||||
ulimit -n 65536 <2>
|
||||
su elasticsearch <3>
|
||||
--------------------------------
|
||||
<1> Become `root`.
|
||||
<2> Change the max number of open files.
|
||||
<3> Become the `elasticsearch` user in order to start Elasticsearch.
|
||||
|
||||
The new limit is only applied during the current session.
|
||||
|
||||
You can consult all currently applied limits with `ulimit -a`.
|
||||
|
||||
|
||||
[[limits.conf]]
|
||||
==== `/etc/security/limits.conf`
|
||||
|
||||
On Linux systems, persistent limits can be set for a particular user by
|
||||
editing the `/etc/security/limits.conf` file. To set the maximum number of
|
||||
open files for the `elasticsearch` user to 65,536, add the following line to
|
||||
the `limits.conf` file:
|
||||
|
||||
[source,sh]
|
||||
--------------------------------
|
||||
elasticsearch - nofile 65536
|
||||
--------------------------------
|
||||
|
||||
This change will only take effect the next time the `elasticsearch` user opens
|
||||
a new session.
|
||||
|
||||
[NOTE]
|
||||
.Ubuntu and `limits.conf`
|
||||
===============================
|
||||
Ubuntu ignores the `limits.conf` file for processes started by `init.d`. To
|
||||
enable the `limits.conf` file, edit `/etc/pam.d/su` and uncomment the
|
||||
following line:
|
||||
|
||||
[source,sh]
|
||||
--------------------------------
|
||||
# session required pam_limits.so
|
||||
--------------------------------
|
||||
===============================
|
||||
|
||||
|
||||
[[sysconfig]]
|
||||
==== Sysconfig file
|
||||
|
||||
When using the RPM or Debian packages, system settings and environment
|
||||
variables can be specified in the system configuration file, which is located
|
||||
in:
|
||||
|
||||
[horizontal]
|
||||
RPM:: `/etc/sysconfig/elasticsearch`
|
||||
Debian:: `/etc/default/elasticsearch`
|
||||
|
||||
However, for systems which uses `systemd`, system limits need to be specified
|
||||
via <<systemd,systemd>>.
|
||||
|
||||
|
||||
[[systemd]]
|
||||
==== Systemd configuration
|
||||
|
||||
When using the RPM or Debian packages on systems that use
|
||||
https://en.wikipedia.org/wiki/Systemd[systemd], system limits must be
|
||||
specified via systemd.
|
||||
|
||||
The systemd service file (`/usr/lib/systemd/system/elasticsearch.service`)
|
||||
contains the limits that are applied by default.
|
||||
|
||||
To override these, add a file called
|
||||
`/etc/systemd/system/elasticsearch.service.d/elasticsearch.conf`) and specify
|
||||
any changes in that file, such as:
|
||||
|
||||
[source,sh]
|
||||
---------------------------------
|
||||
LimitMEMLOCK=infinity
|
||||
---------------------------------
|
||||
|
||||
[[es-java-opts]]
|
||||
==== Setting JVM system properties
|
||||
|
||||
Any Java system properties or arguments which should be passed to the JVM
|
||||
should be specified in the `ES_JAVA_OPTS` environment variable, for instance:
|
||||
|
||||
[source,sh]
|
||||
---------------------------------
|
||||
EXPORT ES_JAVA_OPTS="$ES_JAVA_OPTS -Djava.io.tmpdir=/path/to/temp/dir"
|
||||
./bin/elasticsearch
|
||||
---------------------------------
|
||||
|
||||
When using the RPM or Debian packages, ES_JAVA_OPTS can be specified in the
|
||||
<<sysconfig,system configuration file>>.
|
|
@ -0,0 +1,22 @@
|
|||
[[file-descriptors]]
|
||||
=== File Descriptors
|
||||
|
||||
Elasticsearch uses a lot of file descriptors or file handles. Running out of
|
||||
file descriptors can be disastrous and will most probably lead to data loss.
|
||||
Make sure to increase the limit on the number of open files descriptors for
|
||||
the user running Elasticsearch to 65,536 or higher.
|
||||
|
||||
For the `.zip` and `.tar.gz` packages, set <<ulimit,`ulimit -n 65536`>> as
|
||||
root before starting Elasticsearch, or set `nofile` to `65536` in
|
||||
<<limits.conf,`/etc/security/limits.conf`>>.
|
||||
|
||||
RPM and Debian packages already default the maximum number of file
|
||||
descriptors to 65536 and do not require further configuration.
|
||||
|
||||
You can check the `max_file_descriptors` configured for each node
|
||||
using the <<cluster-nodes-stats>> API, with:
|
||||
|
||||
[source,js]
|
||||
--------------------------------------------------
|
||||
curl 'localhost:9200/_nodes/stats/process?pretty&filter_path=**.max_file_descriptors'
|
||||
--------------------------------------------------
|
|
@ -0,0 +1,36 @@
|
|||
[[heap-size]]
|
||||
=== Set JVM heap size with ES_HEAP_SIZE
|
||||
|
||||
In development mode, Elasticsearch tells the JVM to use a heap with a minimum
|
||||
size of 256MB and a maximum size of 1GB. When moving to production, it is
|
||||
important to configure the `ES_HEAP_SIZE environment variable to ensure that
|
||||
Elasticsearch has enough heap available.
|
||||
|
||||
Elasticsearch will assign the entire heap specified in `ES_HEAP_SIZE on startup.
|
||||
|
||||
The value for this setting depends on the amount of RAM available on your server. A good rule of thumb is:
|
||||
|
||||
* The more heap available to Elasticsearch, the more memory it can use for
|
||||
caching.
|
||||
|
||||
* Set the `ES_HEAP_SIZE` to no more than 50% of your RAM, to ensure that there
|
||||
is enough RAM left for kernel file system caches.
|
||||
|
||||
* Don’t set `ES_HEAP_SIZE` to more than about 31GB to ensure that the JVM uses
|
||||
compressed object pointers (compressed-oops). You can verify that you are
|
||||
under the limit by looking for a line in the logs like the following:
|
||||
|
||||
heap size [1.9gb], compressed ordinary object pointers [true]
|
||||
|
||||
Here are examples of how to set the ES_HEAP_SIZE:
|
||||
|
||||
[source,sh]
|
||||
------------------
|
||||
ES_HEAP_SIZE=2g ./bin/elasticsearch <1>
|
||||
ES_HEAP_SIZE=4000m ./bin/elasticsearch <2>
|
||||
------------------
|
||||
<1> Set the min/max heap size to 2GB.
|
||||
<2> Set the min/max heap size to 4,000MB.
|
||||
|
||||
When using the Debian or RPM package, ES_HEAP_SIZE can be configured in the
|
||||
<<sysconfig,system configuration file>>.
|
|
@ -0,0 +1,104 @@
|
|||
[[setup-configuration-memory]]
|
||||
=== Disable swapping
|
||||
|
||||
Most operating systems try to use as much memory as possible for file system
|
||||
caches and eagerly swap out unused application memory. This can result in
|
||||
parts of the JVM heap being swapped out to disk.
|
||||
|
||||
Swapping is very bad for performance and for node stability and should be
|
||||
avoided at all costs. It can cause garbage collections to last for **minutes**
|
||||
instead of milliseconds and can cause nodes to respond slowly or even to
|
||||
disconnect from the cluster.
|
||||
|
||||
There are three approaches to disabling swapping:
|
||||
|
||||
[[mlockall]]
|
||||
==== Enable `bootstrap.mlockall`
|
||||
|
||||
The first option is to use
|
||||
http://opengroup.org/onlinepubs/007908799/xsh/mlockall.html[mlockall] on Linux/Unix systems, or https://msdn.microsoft.com/en-us/library/windows/desktop/aa366895%28v=vs.85%29.aspx[VirtualLock] on Windows, to
|
||||
try to lock the process address space into RAM, preventing any Elasticsearch
|
||||
memory from being swapped out. This can be done, by adding this line
|
||||
to the `config/elasticsearch.yml` file:
|
||||
|
||||
[source,yaml]
|
||||
--------------
|
||||
bootstrap.mlockall: true
|
||||
--------------
|
||||
|
||||
WARNING: `mlockall` might cause the JVM or shell session to exit if it tries
|
||||
to allocate more memory than is available!
|
||||
|
||||
After starting Elasticsearch, you can see whether this setting was applied
|
||||
successfully by checking the value of `mlockall` in the output from this
|
||||
request:
|
||||
|
||||
[source,sh]
|
||||
--------------
|
||||
curl 'http://localhost:9200/_nodes?pretty&filter_path=**.mlockall'
|
||||
--------------
|
||||
|
||||
If you see that `mlockall` is `false`, then it means that the `mlockall`
|
||||
request has failed. You will also see a line with more information in the
|
||||
logs with the words `Unable to lock JVM Memory`.
|
||||
|
||||
The most probable reason, on Linux/Unix systems, is that the user running
|
||||
Elasticsearch doesn't have permission to lock memory. This can be granted as follows:
|
||||
|
||||
`.zip` and `.tar.gz`::
|
||||
|
||||
Set <<ulimit,`ulimit -l unlimited`>> as root before starting Elasticsearch,
|
||||
or set `memlock` to `unlimited` in
|
||||
<<limits.conf,`/etc/security/limits.conf`>>.
|
||||
|
||||
RPM and Debian::
|
||||
|
||||
Set `MAX_LOCKED_MEMORY` to `unlimited` in the
|
||||
<<sysconfig,system configuration file>> (or see below for systems using `systemd`).
|
||||
|
||||
Systems using `systemd`::
|
||||
|
||||
Set `LimitMEMLOCK` to `infinity` in the <<systemd,systemd configuration>>.
|
||||
|
||||
|
||||
Another possible reason why `mlockall` can fail is that the temporary directory
|
||||
(usually `/tmp`) is mounted with the `noexec` option. This can be solved by
|
||||
specifying a new temp directory, by starting Elasticsearch with:
|
||||
|
||||
[source,sh]
|
||||
--------------
|
||||
./bin/elasticsearch -Djava.io.tmpdir=/path/to/temp/dir
|
||||
--------------
|
||||
|
||||
or using the `ES_JAVA_OPTS` environment variable:
|
||||
|
||||
[source,sh]
|
||||
--------------
|
||||
export ES_JAVA_OPTS="$ES_JAVA_OPTS -Djava.io.tmpdir=/path/to/temp/dir"
|
||||
./bin/elasticsearch
|
||||
--------------
|
||||
|
||||
[[disable-swap-files]]
|
||||
==== Disable all swap files
|
||||
|
||||
The second option is to completely disable swap. Usually Elasticsearch
|
||||
is the only service running on a box, and its memory usage is controlled
|
||||
by the `ES_HEAP_SIZE` environment variable. There should be no need
|
||||
to have swap enabled.
|
||||
|
||||
On Linux systems, you can disable swap temporarily
|
||||
by running: `sudo swapoff -a`. To disable it permanently, you will need
|
||||
to edit the `/etc/fstab` file and comment out any lines that contain the
|
||||
word `swap`.
|
||||
|
||||
On Windows, the equivalent can be achieved by disabling the paging file entirely
|
||||
via `System Properties → Advanced → Performance → Advanced → Virtual memory`.
|
||||
|
||||
[[swappiness]]
|
||||
==== Configure `swappiness`
|
||||
|
||||
The second option available on Linux systems is to ensure that the sysctl value
|
||||
`vm.swappiness` is set to `1`. This reduces the kernel's tendency to swap and
|
||||
should not lead to swapping under normal circumstances, while still allowing
|
||||
the whole system to swap in emergency conditions.
|
||||
|
|
@ -0,0 +1,12 @@
|
|||
[[max-number-of-threads]]
|
||||
=== Number of threads
|
||||
|
||||
Elasticsearch uses a number of thread pools for different types of operations.
|
||||
It is important that it is able to created new threads whenever needed. Make
|
||||
sure that the number of threads that the Elasticsearch user can create is at
|
||||
least 2048.
|
||||
|
||||
This can be done by setting <<ulimit,`ulimit -u 2048`>> as root before
|
||||
starting Elasticsearch, or by setting `nproc` to `2048` in
|
||||
<<limits.conf,`/etc/security/limits.conf`>>.
|
||||
|
|
@ -0,0 +1,20 @@
|
|||
[[vm-max-map-count]]
|
||||
=== Virtual memory
|
||||
|
||||
Elasticsearch uses a <<default_fs,`hybrid mmapfs / niofs`>> directory by
|
||||
default to store its indices. The default operating system limits on mmap
|
||||
counts is likely to be too low, which may result in out of memory exceptions.
|
||||
|
||||
On Linux, you can increase the limits by running the following command as
|
||||
`root`:
|
||||
|
||||
[source,sh]
|
||||
-------------------------------------
|
||||
sysctl -w vm.max_map_count=262144
|
||||
-------------------------------------
|
||||
|
||||
To set this value permanently, update the `vm.max_map_count` setting in
|
||||
`/etc/sysctl.conf`. To verify after rebooting, run `sysctl vm.max_map_count`.
|
||||
|
||||
The RPM and Debian packages will configure this setting automatically. No
|
||||
further configuration is required.
|
|
@ -7,8 +7,9 @@ Before upgrading Elasticsearch:
|
|||
|
||||
* Consult the <<breaking-changes,breaking changes>> docs.
|
||||
* Test upgrades in a dev environment before upgrading your production cluster.
|
||||
* Always back up your data before upgrading. You cannot roll back to an earlier
|
||||
version unless you have a <<backup,backup>> of your data.
|
||||
* Always <<modules-snapshots,back up your data>> before upgrading.
|
||||
You **cannot roll back** to an earlier version unless you have a backup of your data.
|
||||
* If you are using custom plugins, check that a compatible version is available.
|
||||
===========================================
|
||||
|
||||
Elasticsearch can usually be upgraded using a rolling upgrade process,
|
||||
|
@ -21,33 +22,14 @@ consult this table:
|
|||
[cols="1<m,1<m,3",options="header",]
|
||||
|=======================================================================
|
||||
|Upgrade From |Upgrade To |Supported Upgrade Type
|
||||
|0.90.x |2.x |<<restart-upgrade,Full cluster restart>>
|
||||
|1.x |2.x |<<restart-upgrade,Full cluster restart>>
|
||||
|2.x |2.y |<<rolling-upgrades,Rolling upgrade>> (where `y > x `)
|
||||
|2.x |3.x |<<restart-upgrade,Full cluster restart>>
|
||||
|2.x |2.y |<<rolling-upgrades,Rolling upgrade>> (where `y > x`)
|
||||
|5.x |5.y |<<rolling-upgrades,Rolling upgrade>> (where `y > x`)
|
||||
|2.x |5.x |<<restart-upgrade,Full cluster restart>>
|
||||
|5.0.0-alpha1 |5.y |<<restart-upgrade,Full cluster restart>>
|
||||
|5.0.0-alpha2 |5.y |<<restart-upgrade,Full cluster restart>>
|
||||
|5.0.0-beta1 |5.y |<<restart-upgrade,Full cluster restart>>
|
||||
|=======================================================================
|
||||
|
||||
===========================================
|
||||
Upgrading Elasticsearch with Plugins
|
||||
|
||||
Take plugins into consideration as well when upgrading. Plugins must be upgraded alongside Elasticsearch.
|
||||
|
||||
Check with your plugin's provider to ensure that the plugin is compatible with
|
||||
your targeted version of Elasticsearch. If doing a rolling upgrade, it may be
|
||||
worth checking as well that the plugin works across a mixed-version cluster.
|
||||
|
||||
The process for both <<rolling-upgrades,Rolling upgrade>> and
|
||||
<<restart-upgrade,Full cluster restart>> is generally as follows, per node.
|
||||
|
||||
* Shut down Elasticsearch
|
||||
* Upgrade Elasticsearch
|
||||
* Upgrade Plugins
|
||||
* Start up Elasticsearch
|
||||
|
||||
===========================================
|
||||
|
||||
include::backup.asciidoc[]
|
||||
|
||||
include::rolling_upgrade.asciidoc[]
|
||||
|
||||
include::cluster_restart.asciidoc[]
|
||||
|
|
Loading…
Reference in New Issue