Elasticsearch Reference 5.5 中文翻译4

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.

理想的情况，Elasticsearch应当运行在一个服务器上并且使用所有可用的资源。为了实现这个目的，你需要配置你的操作系统允许用户运行Elasticsearch来访问更多的资源在默认的情况下。

 

The following settings must be addressed before going to production:

下面的设置必须在进入生产环境之前完成配置：

 

    Set JVM heap size

设置JVM的堆大小

    Disable swapping

关闭内存交换

    Increase file descriptors

提高文件描述符

    Ensure sufficient virtual memory

允许足够的虚拟内存

    Ensure sufficient threads

保证足够的线程数目

 

Development mode vs production mode

开发模式vs生产模式

 

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.

默认的，Elasticsearch假设你是运行在开发模式下。如果任何设置配置存在错误，将会在日志文件记录警告，但是你依然可以启动和运行你的Elasticsearch节点。

 

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.

由于你配置的网络类似于network.host，Elasticsearch假设你进入了生产环境并且将会提高级别将警告升级为异常。这些异常将会阻止你启动Elasticsearch。这是很重要的保证你不会因为错误的配置而丢失数据。

 

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.

为了配置系统设置依赖于你选择什么样的方式来安装Elasticsearch和你使用的操作系统。

 

When using the .zip or .tar.gz packages, system settings can be configured:

当你使用zip或tar.gz的安装包是，系统设置可以被配置如下：

 

    temporarily with ulimit, or

    permanently in /etc/security/limits.conf.

 

When using the RPM or Debian packages, most system settings are set in the system configuration file. However, systems which use systemd require that system limits are specified in a systemd configuration file.

当使用RPM或Debian的安装包时，大部分系统设置在系统配置文件中。然而，使用systemd要求系统限制被指定在systemd的配置文件中。

 

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:

在Linux系统中，ulimit可以被使用来改变资源限制于临时的使用。限制童谣需要被root来设置在切换用户运行Elasticsearch之前。例如，为了设置打开文件的数量，你可以操作如下：

 

sudo su  //1

ulimit -n 65536 //2

su elasticsearch //3

 

1，Become root.

切换为root用户

2，Change the max number of open files.

改变打开的文件最大数目

3，Become the elasticsearch user in order to start Elasticsearch.

切换回elasticsearch用户用于启动Elasticsearch。

 

The new limit is only applied during the current session.

如果只想应用于单签的会话。

 

You can consult all currently applied limits with ulimit -a.

你可以使用例如ulimit -a

 

/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:

对于Linux系统，永久的限制可以被设置对于指定的用户通过编辑/etc/security/limits.conf文件。为了设置最大打开的文件数目用于Elasticsearch用户为65536，添加下面的内容到limits.conf文件中：

 

elasticsearch  -  nofile  65536

 

This change will only take effect the next time the elasticsearch user opens a new session.

这个改变将会在Elasticsearch开启一个新的会话时生效。

 

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:

Ubuntu忽略limits.conf文件对于init.d启动的过程。为了开启limits.conf文件，编辑/etc/pam.d/su并且取消下面行的注释：

 

# session    required   pam_limits.so

 

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:

当使用RPM或Debian安装包时，系统设置和环境变量可以被指定在系统配置文件中，位于：

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 systemd, system limits must be specified via systemd.

当使用RPM或Debian安装包的系统使用systemd，系统限制必须通过systemd来指定。

 

The systemd service file (/usr/lib/systemd/system/elasticsearch.service) contains the limits that are applied by default.

systemd服务文件（/usr/lib/systemd/system/elasticsearch.service）包含了应用的默认限制。

 

To override these, add a file called /etc/systemd/system/elasticsearch.service.d/elasticsearch.conf and specify any changes in that file, such as:

为了避免这些，添加一个文件名字为/etc/systemd/system/elasticsearch.service.d/elasticsearch.conf并且指定改变在文件中。例如：

 

[Service]

LimitMEMLOCK=infinity

 

Setting JVM options

设置JVM选项

 

The preferred method of setting Java Virtual Machine options (including system properties and JVM flags) is via the jvm.options configuration file. The default location of this file is config/jvm.options (when installing from the tar or zip distributions) and /etc/elasticsearch/jvm.options (when installing from the Debian or RPM packages). This file contains a line-delimited list of JVM arguments, which must begin with -. You can add custom JVM flags to this file and check this configuration into your version control system.

最好的设置JVM选项的方式（包括系统属性和JVM标志）是通过jvm.options的配置文件。默认的文件位置是config/jvm.options（当使用tar或zip安装时）或/etc/elasticsearch/jvm.options（当使用Debian或RPM包安装时）。这个文件包含JVM参数的行分隔列表，要求由-开始。你可以添加自定义的JVM标志到这个文件并且检查这个配置和你的版本管理系统中的内容。

 

An alternative mechanism for setting Java Virtual Machine options is via the ES_JAVA_OPTS environment variable. For instance:

另一种策略来配置Java虚拟机是通过ES_JAVA_OPTS环境变量。例如：

 

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 system configuration file.

当使用RPM或Debian安装包时，ES_JAVA_OPTS可以被指定在系统配置文件中。

 

Set JVM heap size via jvm.options

通过jvm.options来设置JVM的堆大小

 

By default, Elasticsearch tells the JVM to use a heap with a minimum and maximum size of 2 GB. When moving to production, it is important to configure heap size to ensure that Elasticsearch has enough heap available.

默认的，Elasticsearch告诉JVM使用最小大小的堆和最大为2GB。当在生产中使用，重要是配置堆大小保证Elasticsearch有足够的堆空间。

 

Elasticsearch will assign the entire heap specified in jvm.options via the Xms (minimum heap size) and Xmx (maximum heap size) settings.

Elasticsearch将会分配所有的堆指定的jvm.opions中通过Xms（最小堆大小）和Xmx（最大堆大小）的设置。

 

The value for these setting depends on the amount of RAM available on your server. Good rules of thumb are:

这些设置的值依赖于服务器上可用的RAM。好的建议规则如下：

 

    Set the minimum heap size (Xms) and maximum heap size (Xmx) to be equal to each other.

设置最小堆大小和最大堆大小互相相等。

    The more heap available to Elasticsearch, the more memory it can use for caching. But note that too much heap can subject you to long garbage collection pauses.

对于ELasticsearch的堆大小越多，它可以使用缓存的空间就越多。但是注意这会导致长期的垃圾回收暂停。

    Set Xmx to no more than 50% of your physical RAM, to ensure that there is enough physical RAM left for kernel file system caches.

设置Xms不要超过物理内存的50%，保证有足够的物理内存用于系统的内核文件缓存。

 

    Don’t set Xmx to above the cutoff that the JVM uses for compressed object pointers (compressed oops); the exact cutoff varies but is near 32 GB. You can verify that you are under the limit by looking for a line in the logs like the following:

不要设置Xmx超过JVM用于压缩的点（压缩操作）；实际的限制是32GB。你可以验证下面的限制通过在日志中找到类似如下的一行：

 

    heap size [1.9gb], compressed ordinary object pointers [true]

 

    Even better, try to stay below the threshold for zero-based compressed oops; the exact cutoff varies but 26 GB is safe on most systems, but can be as large as 30 GB on some systems. You can verify that you are under the limit by starting Elasticsearch with the JVM options -XX:+UnlockDiagnosticVMOptions -XX:+PrintCompressedOopsMode and looking for a line like the following:

最好，降低从零开始的压缩的门槛；26GB是一个安全的值对于大部分系统，但是在一些系统中32GB可能是比较大的值。你可以指定这些限制通过开启Elasticsearch时使用JVM选项-XX:+UnlockDiagnosticVMOptions -XX:+PrintCompressedOopsMode和找到类似如下的内容：

 

    heap address: 0x000000011be00000, size: 27648 MB, zero based Compressed Oops

 

    showing that zero-based compressed oops are enabled instead of

展示从零开始压缩操作是被启用的代替

 

    heap address: 0x0000000118400000, size: 28672 MB, Compressed Oops with base: 0x00000001183ff000

 

Here are examples of how to set the heap size via the jvm.options file:

这里是如何使用jvm.opions文件来设置堆大小

 

-Xms2g //1

-Xmx2g //2

 

1，Set the minimum heap size to 2g.

设置最小堆大小为2G

2，Set the maximum heap size to 2g.

设置最大堆大小为2G

 

It is also possible to set the heap size via an environment variable. This can be done by commenting out the Xms and Xmx settings in the jvm.options file and setting these values via ES_JAVA_OPTS:

可以设置堆大小通过环境变量。这可以使用Xms和Xmx设置在jvm.opions文件中和设置这些值通过ES_JAVA_OPTS：

 

ES_JAVA_OPTS="-Xms2g -Xmx2g" ./bin/elasticsearch //1

ES_JAVA_OPTS="-Xms4000m -Xmx4000m" ./bin/elasticsearch //2

 

1，Set the minimum and maximum heap size to 2 GB.

设置最大堆大小为2G

2，Set the minimum and maximum heap size to 4000 MB.

设置最小堆大小为2G

 

Note

注意

 

Configuring the heap for the Windows service is different than the above. The values initially populated for the Windows service can be configured as above but are different after the service has been installed. Consult the Windows service documentation for additional details.

配置Windows服务的堆大小和上面展示的不同。初始值用于Windows服务器可以被配置但是不同于在服务安装之后。参考https://www.elastic.co/guide/en/elasticsearch/reference/5.5/zip-windows.html#windows-service来了解更多细节。

 

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 or even its executable pages being swapped out to disk.

大部分操作系统会使用更多的内存对于文件系统缓存并且频繁交换未使用的应用内存。这可能导致在JVM堆中的一部分或甚至他的执行页可能被交换到硬盘。

 

Swapping is very bad for performance, 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. In a resilient distributed system, it’s more effective to let the operating system kill the node.

交换对于性能是有很大的影响，以及节点的稳定并且应当避免消耗。他可以导致垃圾回收时间持续几分钟而不是几毫秒并且可能导致集群变慢。在一个可扩展的集群系统中，最有效的方式是让操作系统杀死节点。

 

There are three approaches to disabling swapping. The preferred option is to completely disable swap. If this is not an option, whether or not to prefer minimizing swappiness versus memory locking is dependent on your environment.

有三种方式可以关闭交换。最好的选择是完全关闭交换。如果这不是一个方法，会有一些对交换内存的锁定并且依赖你的环境。

 

Disable all swap files

关闭所有的交换文件

 

Usually Elasticsearch is the only service running on a box, and its memory usage is controlled by the JVM options. There should be no need to have swap enabled.

通常Elasticsearch只是一个服务运行于机器上并且他的内存使用是由JVM选项来控制的。这不需要开启交换功能。

 

On Linux systems, you can disable swap temporarily by running:

在Linux系统上，你可以通过下面的命令临时关闭内存交换：

 

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.

为了永久关闭，你需要编辑/etc/fstab文件并且注释有关包含swap单词的内容行。

 

On Windows, the equivalent can be achieved by disabling the paging file entirely via System Properties→ Advanced → Performance→ Advanced→ Virtual memory.

对于Windows，可以通过下面的方式关闭，系统属性——》高级——》性能-》高级-》虚拟内存。

 

Configure swappiness

配置swappiness

 

Another 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.

另一种在Linux系统上可用的方法就是保证sysctl值vm.swappiness被设置为1。这减少了内核对于交换的倾向并且不会在正常情况下引起交换，但是依然允许在紧急情况下交换内存。

 

Enable bootstrap.memory_lock

开启bootstrap.memory_lock

 

Another option is to use mlockall on Linux/Unix systems, or 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:

另一种方式在Linux或Unix系统上使用mlockall或者在Windows的VirtualLock中就是尝试锁定执行地址空间在RAM中，阻止任何Elasticsearch内存的交换操作。这可以通过在配置文件config/elasticsearch.yml中添加如下的内容：

 

bootstrap.memory_lock: true

 

Warning

警告

 

mlockall might cause the JVM or shell session to exit if it tries to allocate more memory than is available!

mlockall可能导致JVM或shell的会话退出如果他试图锁定更多可用的内存的话！

 

After starting Elasticsearch, you can see whether this setting was applied successfully by checking the value of mlockall in the output from this request:

在启动Elasticsearch之后，你可以看到这个设置被成功的应用通过检查mlockall的值在输出中通过如下的请求：

 

GET _nodes?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.

如果你看到mlockall是false的话，就意味侄儿mlockall的请求已经失败了。你将会看到一行更多的消息在日志中类似于不能锁定JVM内存字样。

 

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:

最好的理由，在Linux或Unix系统中，用户运行Elasticsearch没有锁定内存的权限。这可以通过下面的命令在赋予：

 

.zip and .tar.gz

    Set ulimit -l unlimited as root before starting Elasticsearch, or set memlock to unlimited in /etc/security/limits.conf.

在启动Elasticsearch之前设置ulimit -l unlimited在root用户下，或在文件/etc/security/limits.conf中设置memlock为unlimited。

RPM and Debian

    Set MAX_LOCKED_MEMORY to unlimited in the system configuration file (or see below for systems using systemd).

在系统的配置文件中设置MAX_LOCKED_MEMORY为unlimited（将下面使用systmd）

Systems using systemd

    Set LimitMEMLOCK to infinity in the systemd configuration.

在systmd配置中设置LimitMEMLOCK为infinity。

 

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 using the ES_JAVA_OPTS environment variable:

另一个理由关于mlockall事变是临时的目录（usually/tmp）是挂载使用了noexec选项。这可以通过指定新的临时目录使用ES_JAVA_OPTS环境变量来实现：

 

export ES_JAVA_OPTS="$ES_JAVA_OPTS -Djava.io.tmpdir=/path/to/temp/dir"

./bin/elasticsearch

 

or setting this JVM flag in the jvm.options configuration file.

或设置JVM标志在jvm.options配置文件中。

 

File Descriptors

文件描述符

 

Note

注意

 

This is only relevant for Linux and macOS and can be safely ignored if running Elasticsearch on Windows. On Windows that JVM uses an API limited only by available resources.

这只适用于Linux和macOS并且可以被忽略如果是在Windows上运行Elasticsearch的话。对于WIndows的话，JVM使用API限制于可用的资源。

 

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.

Elasticsearch使用许多的文件描述符和文件句柄。泄露的文件描述符可能是有破坏性的并且将可能导致数据的丢失。为了保证打开文件描述符的数量限制对于用户运行Elasticsearch要求65536或者更高。

 

For the .zip and .tar.gz packages, set ulimit -n 65536 as root before starting Elasticsearch, or set nofile to 65536 in /etc/security/limits.conf.

对于zip和tar.gz包，设置ulimit -n 65536使用root权限在运行Elasticsearch之前或者设置nofile为65536在/etc/security/limits.conf文件中。

 

RPM and Debian packages already default the maximum number of file descriptors to 65536 and do not require further configuration.

RPM和Debian包已经默认是文件描述符的最大值为65536并且不会要求更多的配置。

 

You can check the max_file_descriptors configured for each node using the Nodes Stats API, with:

你可以检查max_file——descriptors配置对于每个节点使用Nodes Status API如下：

 

GET _nodes/stats/process?filter_path=**.max_file_descriptors

 

Virtual memory

虚拟内存

 

Elasticsearch uses a mmapfs directory by default for 64bit systems 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.

Elasticsearch使用mmapfs的目录在默认情况下对于64位的集群来存储他的目录。默认的操作系统限制对于ummap的计数是很少的，将有可能导致内存异常。

 

On Linux, you can increase the limits by running the following command as root:

在Linux中，你可以增加限制通过以root身份运行如下的命令：

 

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.

为了永久的设置这个值，更新/etc/sysctl.conf中的vm.max_map_count设置。需要在重启后生效，可以通过运行sysctl vm.max_map_count命令来验证。

 

The RPM and Debian packages will configure this setting automatically. No further configuration is required.

RPM和Debian包将自动配置这个设置。不需要额外的设置。

 

Number of threads

线程的数目

 

Elasticsearch uses a number of thread pools for different types of operations. It is important that it is able to create new threads whenever needed. Make sure that the number of threads that the Elasticsearch user can create is at least 2048.

Elasticsearch使用一定数量的线程池用于不同类型的操作。这是很重要的对于根据需要来创建线程池。保证线程的数目对于Elasticsearch用户的使用可以创建至少2048个线程。

 

This can be done by setting ulimit -u 2048 as root before starting Elasticsearch, or by setting nproc to 2048 in /etc/security/limits.conf.

这个可以通过以root身份运行ulimit -u 2048在运行Elasticsearch之前，或设置nproc为2048在配置文件/etc/security/limits.conf中。

 

Upgrading Elasticsearch

更新Elasticsearch

 

Important

重要

 

Before upgrading Elasticsearch:

在更新Elasticsearch之前：

 

    Consult the breaking changes docs.

查阅相应的更新文档。

    Use the Elasticsearch Migration Plugin to detect potential issues before upgrading.

使用Elasticsearch Migration插件来探测升级之前的潜在问题。

    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 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, resulting in no interruption of service. This section details how to perform both rolling upgrades and upgrades with full cluster restarts.

Elasticsearch通常可以升级使用滚动升级程序，将不会中断服务。这个章节将讨论如何执行滚动升级和升级所有的集群。

 

To determine whether a rolling upgrade is supported for your release, please consult this table:

为了判断你的集群是否支持滚动升级，请参考下面的表格：

Upgrade From

升级之前的版本

Upgrade To

升级之后的版本

Supported Upgrade Type

支持的升级类型

1.x

5.x

Reindex to upgrade

重新索引升级

2.x

2.y

Rolling upgrade (where y > x)

滚动升级（要求y高于x）

2.x

5.x

Full cluster restart

全部集群重启

5.0.0 pre GA

5.x

Full cluster restart

全部集群重启

5.x

5.y

Rolling upgrade (where y > x)

滚动升级（要求y高于x）

 

Important

重要

 

Indices created in Elasticsearch 1.x or before

在Elasticsearch1.x或之前的版本中创建目录

 

Elasticsearch is able to read indices created in the previous major version only. For instance, Elasticsearch 5.x can use indices created in Elasticsearch 2.x, but not those created in Elasticsearch 1.x or before.

Elasticsearch只可以读取创建之前版本中的目录。因此，Elasticsearch5.x可以使用在Elasticsearch2.x中创建的目录，但是不能使用在Elasticsearch1.x中创建的目录。

 

This condition also applies to indices backed up with snapshot and restore. If an index was originally created in 1.x, it cannot be restored into a 5.x cluster even if the snapshot was made by a 2.x cluster.

这个情况适用于使用快照恢复目录。如果索引是在1.x版本中创建的，他不能恢复到5.x的集群中不管是2.x集群制作的快照。

 

Elasticsearch 5.x nodes will fail to start in the presence of too old indices.

Elasticsearch5.x的节点会失败在启动的时候由于陈旧的版本。

 

See Reindex to upgrade for more information about how to upgrade old indices.

参考https://www.elastic.co/guide/en/elasticsearch/reference/5.5/reindex-upgrade.html来了解更多信息有关如何更新陈旧的内容。

 

Rolling upgrades

滚动升级

 

A rolling upgrade allows the Elasticsearch cluster to be upgraded one node at a time, with no downtime for end users. Running multiple versions of Elasticsearch in the same cluster for any length of time beyond that required for an upgrade is not supported, as shards will not be replicated from the more recent version to the older version.

滚动升级允许Elasticsearch集群被同时升级而不需要停止终端用户的使用。在相同的集群中运行多个版本的Elasticsearch对于升级是不被支持的，因此分表将不会被备份对于过期版本。

 

Consult this table to verify that rolling upgrades are supported for your version of Elasticsearch.

考虑下面的内容来验证滚动升级的功能是否在你使用的Elasticsearch的版本中支持。

 

To perform a rolling upgrade:

为了执行滚动升级：

 

    1，Disable shard allocation

关闭分配分片

 

    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:

当你关闭一个节点，分配程序将会等待一分钟在你启动这个复制分片之前由于这个节点在集群中，需要浪费很多的IO。这可以通过在关闭节点前关闭分配来避免。

 

    PUT _cluster/settings

    {

      "transient": {

        "cluster.routing.allocation.enable": "none"

      }

    }

 

    2，Stop non-essential indexing and perform a synced flush (Optional)

关闭不必要的索引和执行synced的刷新（可选）

 

    You may happily continue indexing during the upgrade. However, shard recovery will be much faster if you temporarily stop non-essential indexing and issue a synced-flush request:

你可以继续索引在升级的过程中。然而，分片的恢复将会更加的迅速如果你临时关闭了一部分不必要的索引并且发送了一个synced-flush的请求之后：

 

    POST _flush/synced

 

    A synced flush request is a “best effort”operation. It will fail if there are any pending indexing operations, but it is safe to reissue the request multiple times if necessary.

一个synced刷新星球是最好的操作。他会失败如果存在任何待定的索引操作但是他是安全的对于多次发出这个请求。

 

    3，Stop and upgrade a single node

关闭和升级单个节点

 

    Shut down one of the nodes in the cluster before starting the upgrade.

关闭集群中的一个节点在启动升级之前。

    Tip

提示

 

    When using the zip or tarball packages, the config, data, logs and plugins directories are placed within the Elasticsearch home directory by default.

当使用zip或tarball包是，config、data、log和插件目录将被默认的Elasticsearch目录替换。

 

    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 configured with the path.conf, path.logs, and path.data settings, and using ES_JVM_OPTIONS to specify the location of the jvm.options file.

将这些目录放置在其他的位置是一种很好的选择并且不需要在升级Elasticsearch时改变他们。这些集群的路径可以被配置使用path.conf、path.logs和path.data的设置并且使用ES_JVM_OPTIONS来指定jvm.options文件的位置。

 

    The Debian and RPM packages place these directories in the appropriate place for each operating system.

Debina和RPM包将这些目录放置在不同操作系统的适当的位置上。

 

    To upgrade using a Debian or RPM package:

为了升级使用Debian或RPM包的情况

        Use rpm or dpkg to install the new package. All files should be placed in their proper locations, and config files should not be overwritten.

使用rpm或dpkg来安装新的包。所有的文件将会被替代根据他们的位置并且但是配置文件不会被覆盖。

 

    To upgrade using a zip or compressed tarball:

使用zip或压缩的tarball的升级的情况：

        Extract the zip or tarball to a new directory, to be sure that you don’t overwrite the config or data directories.

及压缩zip或tarball包到新的目录，保证没有覆盖config或data目录

        Either copy the files in the config directory from your old installation to your new installation, or set the environment variable ES_JVM_OPTIONS to the location of the jvm.options file and use the -E path.conf= option on the command line to point to an external config directory.

在原来的实例中复制cofig目录到新的安装的位置或设置ES_JVM_OPTIONS的变量对于jvm.options的文件的位置使用-E path.conf的选项在命令行来指定额外的配置文件目录。

        Either copy the files in the data directory from your old installation to your new installation, or configure the location of the data directory in the config/elasticsearch.yml file, with the path.data setting.

复制原有实例的data目录到新的位置，或配置数据目录的位置在config/elasticsearch.yml文件中使用path.data设置。

 

    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.

Elasticsearch插件必须被更新当升级一个节点的时候。使用elasticsearch-plugin脚本来安装你需要的正确的插件版本。

 

    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:

开启更新后的节点并且确认他加入到集群中通过检查日志文件或通过下面请求的输出返回：

 

    GET _cat/nodes

 

    6，Reenable shard allocation

刷新分片的分配

 

    Once the node has joined the cluster, reenable shard allocation to start using the node:

一旦节点加入了集群，重新开启分片分配对于使用下面的命令在节点上：

 

    PUT _cluster/settings

    {

      "transient": {

        "cluster.routing.allocation.enable": "all"

      }

    }

 

    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 request:

你应当等待节点完成分片的分配在升级下一个节点之前。你可以检查进度通过命令如下：

 

    GET _cat/health

 

    Wait for the status column to move from yellow to green. Status green means that all primary and replica shards have been allocated.

等待status栏从yellow编程green。状态为green意味着所有主要和复制分片已经被分配了。

    Important

重要

 

    During a rolling upgrade, primary shards assigned to a node with the higher version will never have their replicas assigned to a node with the lower version, because the newer version may have a different data format which is not understood by the older version.

在滚动升级中，主要分片分配对于节点使用高的版本将不会需要他的分配对于一个低的版本，因为新的版本有不同的数据格式并且不会被旧的版本所理解。

 

    If it is not possible to assign the replica shards to another node with the higher version — e.g. if there is only one node with the higher version in the cluster — then the replica shards will remain unassigned and the cluster health will remain status yellow.

如果米有分配分片对于高级的版本————例如，如果在集群中只有一个高级的版本————则分片将会保留未分配的状态并且集群的状态会保持yellow。

 

    In this case, check that there are no initializing or relocating shards (the init and relo columns) before proceding.

在这种情况下，确认没有未初始化或重新分配的分片在执行之前。

 

    As soon as another node is upgraded, the replicas should be assigned and the cluster health will reach status green.

对于其他节点的升级，分片应当被分配并且集群的状态将会变为状态green。

 

    Shards that have not been sync-flushed may take some time to recover. The recovery status of individual shards can be monitored with the _cat/recovery request:

分片 将不会sync-flushed可能会花费时间来恢复。独立分片的恢复状态可以被监控通过下面的命令：

 

    GET _cat/recovery

 

    If you stopped indexing, then it is safe to resume indexing as soon as recovery has completed.

如果你停止的索引，应当尽快重新开始索引在恢复完成之后。

 

    8，Repeat

重复

 

    When the cluster is stable and the node has recovered, repeat the above steps for all remaining nodes.

当接群是稳定的并且节点已经恢复，重复上面的部分对于所有的节点。

 

Full cluster restart upgrade

所有集群重启升级

 

Elasticsearch requires a full cluster restart when upgrading across major versions. Rolling upgrades are not supported across major versions. Consult this table to verify that a full cluster restart is required.

Elasticsearch要求整个集群重启当升级跨越主版本的时候。滚动升级不支持跨主版本升级。参考https://www.elastic.co/guide/en/elasticsearch/reference/5.5/setup-upgrade.html这个表格的验证是否需要重新整个集群。

 

The process to perform an upgrade with a full cluster restart is as follows:

执行升级的过程对于整个节点如下：

 

    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:

当你关闭一个节点，分配程序将会迅速尝试复制分片对于集群中的其他节点，导致IO的消耗。这可以通过在关闭节点前关闭分配功能来避免。

 

    PUT _cluster/settings

    {

      "persistent": {

        "cluster.routing.allocation.enable": "none"

      }

    }

 

    2，Perform a synced flush

执行synced刷新

 

    Shard recovery will be much faster if you stop indexing and issue a synced-flush request:

分片恢复将会更快如果你停止索引并且使用了synced-flush命令如下：

 

    POST _flush/synced

 

    A synced flush request is a “best effort”operation. It will fail if there are any pending indexing operations, but it is safe to reissue the request multiple times if necessary.

一个synced刷新星球是最好的操作。他会失败如果存在任何待定的索引操作但是他是安全的对于多次发出这个请求。

 

    3，Shutdown and upgrade all nodes

关闭和升级所有节点

 

    Stop all Elasticsearch services on all nodes in the cluster. Each node can be upgraded following the same procedure described in [upgrade-node].

关闭所有的Elasticsearch服务对于集群中的每个节点。每个节点可以被升级通过相同的步骤（升级节点）。

 

    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.

Elasticsearch插件必须被更新当升级一个节点的时候。使用elasticsearch-plugin脚本来安装你需要的正确的插件版本。

 

    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 to start them first. Wait for them to form a cluster and to elect a master before proceeding with the data nodes. You can check progress by looking at the logs.

如果你使用主节点————节点的node.master设置为true（默认值）并且node.data设置为false————则最好先启动主节点。等待形成集群并且选举主节点在对于数据节点之前。你可以通过日志来查看进度。

 

    As soon as the minimum number of master-eligible nodes have discovered each other, they will form a cluster and elect a master. From that point on, the _cat/health and _cat/nodes APIs can be used to monitor nodes joining the cluster:

对于合格的主节点可以被各自探知应当是最小的数量，浙江形成一个集群并且选举一个主节点。对于进度，_cat/health和_cat/nodes的API可以被使用来监控节点加入集群的状态。

 

    GET _cat/health

 

    GET _cat/nodes

 

    Use these APIs to check that all nodes have successfully joined the cluster.

使用这些API来检查所有的进去已经成功加入了集群。

 

    6，Wait for yellow

等待成为yellow

 

    As soon as each node has joined the cluster, it will start to recover any primary shards that are stored locally. Initially, the _cat/health request will report a status of red, meaning that not all primary shards have been allocated.

由于每个节点已经加入的集群，他们会开始恢复主分片对于本地的存储。最初，_cat/health请求将汇报状态为red，意味着没有主分片被指定。

 

    Once each node has recovered its local shards, the status will become yellow, meaning all primary shards have been recovered, but not all replica shards are allocated. This is to be expected because allocation is still disabled.

一旦每个节点恢复了本地的分片，状态将会变成yellow，意味着所有的主分片已经恢复，但是并不是所有的分片都被分配。这是因为分片依然是不可用的。

 

    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 copies. At this point, with all the nodes in the cluster, it is safe to reenable shard allocation:

延迟分片的分配知道所有的节点都加入的集群允许主节点分配分片对于节点的备份已经完成的本地的复制。在这个点之后，所有的集群中的节点就可以安全的重新允许分配了。

 

    PUT _cluster/settings

    {

      "persistent": {

        "cluster.routing.allocation.enable": "all"

      }

    }

 

    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 have recovered.

集群将会启动所有数据节点的分片分批。在这时可以重新启动搜索的索引，但是你的集群应当快速恢复如果你可以延迟索引和搜索直到所有的分片已经被恢复。

 

    You can monitor progress with the _cat/health and _cat/recovery APIs:

你可以监控进度通过使用_cat/health和_cat/recovery的API：

 

    GET _cat/health

 

    GET _cat/recovery

 

    Once the status column in the _cat/health output has reached green, all primary and replica shards have been successfully allocated.

一旦状态栏就是通过_cat/health请求输出的结果成为green时，所有的主分片就已经成功的被分配了。

 

Reindex to upgrade

重新索引的方式升级

 

Elasticsearch is able to use indices created in the previous major version only. For instance, Elasticsearch 5.x can use indices created in Elasticsearch 2.x, but not those created in Elasticsearch 1.x or before.

Elasticsearch只能使用之前主版本中使用的索引。因此，Elasticsearch5.x可以使用Elasticsearch2.x使用的索引，但是不能使用Elasticsearch1.x及之前使用的索引。

 

Note

注意

 

Elasticsearch 5.x nodes will fail to start in the presence of too old indices.

Elasticsearch5.x节点将会使用如果使用了过旧的索引。

 

If you are running an Elasticsearch 2.x cluster which contains indices that were created before 2.x, you will either need to delete those old indices or to reindex them before upgrading to 5.x. See Reindex in place.

如果你在运行一个Elasticsearch2.x的集群包含了2.x之前创建的索引，你需要删除旧的索引或重新索引在升级到5.x之后。详见https://www.elastic.co/guide/en/elasticsearch/reference/5.5/reindex-upgrade.html#reindex-upgrade-inplace。

 

If you are running an Elasticsearch 1.x cluster, you have two options:

如果你运行一个Elasticsearch1.x的集群，你有两个选择：

 

    First upgrade to Elasticsearch 2.4.x, reindex the old indices, then upgrade to 5.x. See Reindex in place.

首先升级到ELasticsearch2.4版本，重新索引旧的索引，然后升级到5.x。见https://www.elastic.co/guide/en/elasticsearch/reference/5.5/reindex-upgrade.html#reindex-upgrade-inplace

    Create a new 5.x cluster and use reindex-from-remote to import indices directly from the 1.x cluster. See Upgrading with reindex-from-remote.

创建一个新的5.x集群并且使用reindex-from-remote来导入索引从1.x的集群。见https://www.elastic.co/guide/en/elasticsearch/reference/5.5/reindex-upgrade.html#reindex-upgrade-remote

 

Time-based indices and retention periods

基于时间的索引和保存期

 

For many use cases with time-based indices, you will not need to worry about carrying old 1.x indices with you to 5.x. Data in time-based indices usually becomes less interesting as time passes. Old indices can be deleted once they fall outside of your retention period.

对于许多用户使用基于时间的基准，你将不需要担心考虑旧的1.x的索引到5.x的版本。基于时间的基准中的数据通常不会随着时间的变化而改变。旧的数据可以立即删除当他们超过保存的期限时。

 

Users in this position can continue to use 2.x until all old 1.x indices have been deleted, then upgrade to 5.x directly.

在这个位置的用户继续使用2.x的版本知道所有旧的1.x版本的索引已经被删除，然后直接升级到5.x的版本。

 

Reindex in place

适当的重新索引

 

The easiest way to reindex old (1.x) indices in place is to use the Elasticsearch Migration Plugin. You will need to upgrade to Elasticsearch 2.3.x or 2.4.x first.

最简单的方式来重新索引旧的索引时使用Elasticsearch的Migration插件。但是首先你需要升级到的Elasticsearch的2.3.x或2.4.x版本。

 

The reindex utility provided in the migration plugin does the following:

在migration插件中提供的重新索引工具是这么做的：

 

    Creates a new index with the Elasticsearch version appended to the old index name (e.g. my_index-2.4.1), copying the mappings and settings from the old index. Refresh is disabled on the new index and the number of replicas is set to 0 for efficient reindexing.

使用Elasticsearch版本创建一个新的索引追加到旧的索引名上（例如，my_index-2.4.1），从旧的索引中复制匹配和设置。关闭对于新索引的刷新并且副本的数目被设置为0对于有效的重新索引。

    Sets the old index to read only to ensure that no data is written to the old index.

设置旧的索引为只读状态来保证没有数据被写入到旧的索引中。

    Reindexes all documents from the old index to the new index.

将旧的索引内容重新索引到新的索引上。

    Resets the refresh_interval and number_of_replicas to the values used in the old index, and waits for the index to become green.

重新设置refresh_interval和number_of_replicas对于旧索引中使用的数值，并且等待索引变成green。

    Adds any aliases that existed on the old index to the new index.

添加别名将已有的旧索引改为新的索引。

    Deletes the old index.

删除旧的索引。

    Adds an alias to the new index with the old index name, e.g. alias my_index points to index my_index-2.4.1.

添加别名对于新的索引使用旧的索引名字（例如，别名my_index指向索引my_index-2.4.1）。

 

At the end of this process, you will have a new 2.x index which can be used by an Elasticsearch 5.x cluster.

在这个过程的最后，你将有一个新的2.x的索引可以使用在Elasticsearch的5.x的集群中。

 

Upgrading with reindex-from-remote

使用远程的重新索引进行升级

 

If you are running a 1.x cluster and would like to migrate directly to 5.x without first migrating to 2.x, you can do so using reindex-from-remote.

如果你正在运行1.x的集群并且希望直接升级到5.x不希望中间经过2.x，你可以使用远程的重新索引来实现。

 

Warning

警告

 

Elasticsearch includes backwards compatibility code that allows indices from the previous major version to be upgraded to the current major version. By moving directly from Elasticsearch 1.x to 5.x, you will have to solve any backwards compatibility issues yourself.

Elasticsearch支持向后兼容的功能允许来自之前主版本的索引升级到当前版本的索引。通过直接将索引从1.x移动到5.x，你将需要自己来处理兼容的问题。

 

You will need to set up a 5.x cluster alongside your existing 1.x cluster. The 5.x cluster needs to have access to the REST API of the 1.x cluster.

你需要设置5.x集群独立于1.x的集群。5.x的集群需要可以通过以REST的API形式来访问1.x的集群。

 

For each 1.x index that you want to transfer to the 5.x cluster, you will need to:

对于每个1.x的索引你希望传输到5.x的集群，你需要这么做：

 

    Create a new index in 5.x with the appropriate mappings and settings. Set the refresh_interval to -1 and set number_of_replicas to 0 for faster reindexing.

创建一个新的索引在5.x中使用适当的匹配和设置。设置refresh_interval为-1并且设置number_of_replicas为0用于快速重新索引。

    Use reindex-from-remote to pull documents from the 1.x index into the new 5.x index.

使用远程重新索引来拉取文档从1.x的集群中到新的5.x的集群中。

    If you run the reindex job in the background (with wait_for_completion set to false), the reindex request will return a task_id which can be used to monitor progress of the reindex job in the task API: GET _tasks/TASK_ID.

如果你在后台运行重新索引的工作（将wait_for_completion设置为false），重新索引的请求将返回一个task_Id用于可以监控重新索引的进程使用task的API：GET _tasks/TASK_ID。

    Once reindex has completed, set the refresh_interval and number_of_replicas to the desired values (the defaults are 30s and 1 respectively).

一旦完成了重新索引，设置refresh_interval和number_of_replicas为需要的值（相应的默认是30s和1）。

    Once the new index has finished replication, you can delete the old index.

一旦新的索引已经完成复制，你可以删除旧的索引。

 

The 5.x cluster can start out small, and you can gradually move nodes from the 1.x cluster to the 5.x cluster as you migrate indices across.

5.x的集群可以小范围的启动，使得你可以更好的考虑将1.x的集群转移到5.x的集群根据你跨越集群的需要。

 

Stopping Elasticsearch

停止Elasticsearch

 

An orderly shutdown of Elasticsearch ensures that Elasticsearch has a chance to cleanup and close outstanding resources. For example, a node that is shutdown in an orderly fashion will remove itself from the cluster, sync translogs to disk, and perform other related cleanup activities. You can help ensure an orderly shutdown by properly stopping Elasticsearch.

有顺序的关闭Elasticsearch保证Elasticsearch可以完成清理以及关闭外部资源。例如，一个节点以正常的方式关闭将会使得自己从集群中脱离，同步传输日志到磁盘上并且执行其他相关的清理工作。你可以保证有顺序的关闭通过适当的方式来停止Elasticsearch。

 

If you’re running Elasticsearch as a service, you can stop Elasticsearch via the service management functionality provided by your installation.

如果你的Elasticsearch是以服务的方式开始运行的，你可以停止Elasticsearch通过服务管理工具，这个工具由你的安装程序来提供。

 

If you’re running Elasticsearch directly, you can stop Elasticsearch by sending control-C if you’re running Elasticsearch in the console, or by sending SIGTERM to the Elasticsearch process on a POSIX system. You can obtain the PID to send the signal to via various tools (e.g., ps or jps):

如果你是直接运行Elasticsearch的，你可以通过Control+C来停止当你是在控制台执行的时候，或者通过发送SIGTERM信号给POSIX系统。你可以获取PID并且向其发送信号通过不同的工具（例如，ps或jps）：

 

$ jps | grep Elasticsearch

14542 Elasticsearch

 

From the Elasticsearch startup logs:

来自Elasticsearch的启动日志：

 

[2016-07-07 12:26:18,908][INFO ][node                     ] [I8hydUG] version[5.0.0-alpha4], pid[15399], build[3f5b994/2016-06-27T16:23:46.861Z], OS[Mac OS X/10.11.5/x86_64], JVM[Oracle Corporation/Java HotSpot(TM) 64-Bit Server VM/1.8.0_92/25.92-b14]

 

Or by specifying a location to write a PID file to on startup (-p <path>):

或者on哥哥指定位置写入PID文件在启动的时候（-p <path>）

 

$ ./bin/elasticsearch -p /tmp/elasticsearch-pid -d

$ cat /tmp/elasticsearch-pid && echo

15516

$ kill -SIGTERM 15516

 

Stopping on Fatal Errors

致命错误导致的停止

 

During the life of the Elasticsearch virtual machine, certain fatal errors could arise that put the virtual machine in a questionable state. Such fatal errors include out of memory errors, internal errors in virtual machine, and serious I/O errors.

在Elasticsearch虚拟机的生命周期中，一定的致命的错误可能导致虚拟机处于瘫痪的状态。例如致命的错误包括内存溢出错误、虚拟机的内部错误和不同的IO错误。

 

When Elasticsearch detects that the virtual machine has encountered such a fatal error Elasticsearch will attempt to log the error and then will halt the virtual machine. When Elasticsearch initiates such a shutdown, it does not go through an orderly shutdown as described above. The Elasticsearch process will also return with a special status code indicating the nature of the error.

当Elasticsearch探测到虚拟机面临致命的错误则Elasticsearch将会尝试记录错误日志并且停止虚拟机。当Elasticsearch实例被这样关闭后，他不会根据上面的描述执行顺序化的关闭。Elasticsearch集成将返回特定的错误来指定错误的原因。

 

JVM internal error

JVM内部错误

128

Out of memory error

内存溢出

127

Stack overflow error

栈溢出错误

126

Unknown virtual machine error

未知虚拟机错误

125

Serious I/O error

一些IO错误

124

Unknown fatal error

未知的致命错误

1