Elasticsearch-8.2（2024/03/26）

What is Elasticsearch?

（8.2）link

You know, for search (and analysis)

Elasticsearch是Elastic Stack中核心的分布式搜索和分析引擎。Logstash和Beats帮助收集，聚合以及丰富你的数据并存储在Elasticsearch。Kibana使你能够交互式地探索、可视化和分享对数据的见解，并管理和监视stack。Elasticsearch用于索引，查询以及分析。

Elasticsearch提供对所有类型的数据的近实时搜索（near real-time）和分析。无论是结构化还是非结构化的文本，数值类型的数据，或者地理位置数据，Elasticsearch都能有效的进行存储并以某种方式进行索引来实现快速查询。你可以不仅仅是简单的数据检索而是可以进一步的对信息进行聚合来发现你数据中的趋势和patterns。随着你的数据和查询体量的增大，Elasticsearch的分布式功能使你的部署能够无缝地（seamless）随之增长。

虽然不是每一个问题都是一个查询问题，Elasticsearch为在各种用例中处理数据提供了速度（speed）和灵活性（flexibility）。

添加一个搜索框（search box）到一个app或者网页中
存储和分析日志，指标以及安全事件数据
使用machine learning自动对你的数据行为构建实时的模型
使用Elasticsearch作为一个存储引擎自动化业务工作流（business workflows）
使用Elasticsearch作为一个管理，集成以及分析空间信息地理信息系统（GIS: geographic information system）
使用Elasticsearch作为一个生物信息学研究工具（ bioinformatics research tool）来存储以及处理基因数据

我们不断的因为用户使用新颖（novel）的搜索方式而感到惊讶（amaze）。但是不管你的使用案例是否类似与这些中的一种，或者你正在使用Elasticsearch解决（tackle）一个新的问题，你在Elasticsearch中处理你数据，文档以及索引都是一样的。

Data in documents and indices

（8.2）link

Elasticsearch是一个分布式的文档存储。Elasticsearch 存储已序列化为 JSON 文档的复杂数据结构，而不是将信息存储为列式数据行。当你的集群中有多个Elasticsearch节点，存储的文档跨集群分布并能立即从任何节点访问。

文档在存储之后，它会被索引（index）并且在能在near real time--一秒内完全的用于搜索。Elasticsearch使用了称为倒排表（inverted index）的数据结构，它能够用于快速的全文检索。inverted index列出了出现在所有文档中的每一个unique word并识别出每一个单词所在的所有文档。

索引（index）可以认为是一个优化后的文档集合，每一篇文档是一个字段（field）的集合，每一个字段是包含数据的一个键值对（key-value pair）。默认情况下，Elasticsearch会索引所有字段中的数据并且每一种索引字段（indexed field）都有专门的优化后的数据结构。例如，text field存储在倒排索引（inverted index）中，numeric和geo field存储在BKD树中。使用每一种字段的数据结构进行组合（assemble）和返回查询结果的能力使得Elasticsearch特别的快。

Elasticsearch同样有schema-less的能力，意味着不用显示的指定如何处理一篇文档中的不同的字段就可以直接对文档进行索引。当开启dynamic mapping后，Elasticsearch能自动的检测并添加新的字段到索引中。默认的行为使得索引以及探索你的数据变得简单。只需要开始索引文档，Elasticsearch就会进行检测并将booleans，floating point，integer values，dates和strings映射成Elasticsearch中合适的数据类型。

最终，当你比Elasticsearch更了解自己的数据并且想要按照自己的方式来处理。你可以定义规则来控制dynamic mappings以及显示的（explicit）定义mapping来完全的控制如何对字段进行存储和索引。

定义你自己的mapping可以让你：

区分出全文检索字段（full-text string ）跟精确匹配字段（exact value string field）
执行特定语言的文本分析
为部分匹配对字段进行优化
使用自定义的date formats
使用geo_point 和 geo_shape这些不能被自动检测的数据类型

基于不同的目的，用不同的方式索引同一个字段通常是很有用的。例如你可能想要将一个字符串字段索引为text field用于全文检索以及keyword用于排序、聚合。或者你可能会选择使用多个语言分词器来处理包含用户输入的内容。

在索引期间应用到full-text字段的analysis chain在查询期间同样需要使用。当你查询一个full-text 字段，在索引中查找term前，它的请求文本（query text）也会经历（undergo）相同的analysis。

Information out: search and analyze

（8.2）link

当使用Elasticsearch作为一个文档存储（document store），检索文档以及文档的元信息（metadata）时，你能够轻松访问全套搜索能力，其能力来源是因为构建在Apache Lucene 搜索引擎库之上。

Elasticsearch提供了一套简单的，容易理解的（coherent）的REST API，用于管理集群，索引以及查询数据。出于测试的目的，你可以简单的通过命令行或者Kibana中的Developer Console直接提交一个请求。在你的应用中，你可以选择语言并使用Elasticsearch client：Java, JavaScript, Go, .NET, PHP, Perl, Python 或者 Ruby。

Searching your data

Elasticsearch REST APIs支持结构化查询（structured query），全文检索，以及复杂的查询，比如query的组合。结构化查询类似你在SQL中构造的查询类型。例如，你可以在employee索引中查询gender和age字段并且根据hire_date字段对匹配的结果进行排序。全文检索会找到满足查询条件的所有的文档并且根据相关性（relevance，how good a match they are for your search terms）排序。

除了查询不同的term，你还可以执行短语查询（phrase search），相似度查询（similarity search），前缀查询（prefix search）以及获得autocomplete suggestions。

想要查询地理位置或者其他数值类型的数据的话，Elasticsearch将这类非文本的数据索引到一个优化后的数据结构（BKD）使得支持高性能的地址位置和数值查询。

你可以使用Elasticsearch中JSON风格的查询语言（Query DSL）来访问所有的查询能力。你也可以构造SQL-style query查询/聚合数据，以及使用JDBC和ODBC驱动使得更多的第三方应用通过SQL使用Elasticsearch。

Analyzing your data

Elasticsearch的聚合（aggregation）能让你构建复杂的数据汇总并获得关键指标的洞见（insight），模式（pattern）以及趋势（trend）。聚合能让你回答下面的问题，而不是仅仅如谚语中所说的needle in a haystack： Near real-time search

haystack中有多少个needle？
needle的平均长度
每个生产商（manufacturer）制造的needle的median length
过去的六个月中，每个月添加到haystack的needle的数量

你可以使用聚合回答更多subtle问题，例如：

最受欢迎的needle生产商是哪家？
是否存在不寻常或者异常的（anomalous）needle？

由于聚合使用了查询中使用的相同的数据结构，所以非常的快，使得可以实时的分析以及可视化你的数据。报表跟dashboard可以随着你的数据的变更而更新，使得你可以基于最新的信息采取措施（take action）。

聚合是跟查询请求一起执行的。你可以在单个请求中对相同的数据进行查询，过滤，以及分析。因为聚合要在某个查询的上下文中计算，你不仅仅能展示70号needle的数量统计，你还能展示满足你的策略的needle：比如说70号的不沾针（non-stick embroidery needles）。

But wait, there’s more

想要自动分析你的时序数据吗？你可以使用machine learning功能创建你的数据中普通行为（normal behavior）的准确基线以及识别出异常模式（anomalous pattern）。使用machine learning，你可以检测下面的信息：

Anomalies related to temporal deviations in values, counts, or frequencies
Statistical rarity
Unusual behaviors for a member of a population

And the best part? 你不需要指定算法，模型或者其他数据科学相关的配置就可以实现上面的功能。

Scalability and resilience: clusters, nodes, and shards

（8.2）link

Elasticsearch总是可用的（available）并且根据你的需要进行扩展。It does this by being distributed by nature。你可以向一个集群中添加服务（节点）来提高承载力（capacity），Elasticsearch可以跨所有可用的节点，自动的分布/查询（distribute/query）数据。不需要overhaul你的应用，Elasticsearch知道如何平衡多个节点的集群来提供扩展以及高可用能力。The more nodes, the merrier。

Elasticsearch是如何工作的？在底层实现中，一个Elasticsearch index只是一个或多个物理分片（physical shards）的逻辑组合（logical grouping）。每一个分片实际上是一个self-contained index。通过将索引中的文档分布到多个分片，将分片分布到多个节点，Elasticsearch可以确保冗余（ensure redundancy），使得应对硬件故障以及节点添加到集群后，查询能力的提升。随着集群的增长（收缩），Elasticsearch能自动的迁移（migrate）分片来rebalance集群。

分片的类型有两种：主分片跟副本分片（primary and replica shard）。索引中的每一篇文档属于某一个主分片。一个副本分片是某个主分片的拷贝。副本分片提供了数据的冗余来应对硬件故障以及提高例如查询或者检索一篇文档的读取请求的能力。

某个索引中的主分片数量在索引创建后就固定了。但是副本分配的数量可以在任何时间内更改，不会影响（interrupt）索引或者查询操作。

It depends…

对于分片大小和索引的主分片数量，有很多性能考虑点以及trade off。分片越多，维护这些索引的开销就越大。分片大小越大，当Elasticsearch需要rebalance集群时，移动分片花费的时间越大。

在很多较小的分片上查询时，在每一个分片上的查询很快，但是分片越多，查询次数就越多，开销就越大，所以在数量较小，体积较大的分片上的查询可能就更快。In short…it depends。

As a starting point：

将分片的平均大小保持在几个GB以及十几个GB之间。对于基于时间的数据，通常来说，分片的大小在20GB到40GB之间
避免出现大量分片的问题。一个节点可以拥有的分片数量跟可用的堆内存成正比。一般来说（as a general rule），每1GB的堆内存中的分片数量应该小于20个。

对于你的用例，确定最佳配置的最好方式是通过testing with your own data and queries。

In case of disaster

集群中的节点之间需要良好的，可靠的连接。若要能提供一个较好的连接，你通常会将节点放在相同的数据中心或者附近的数据中心。然而为了高可用，你同样需要避免单点故障（single point of failure）。某个地区（location）发生停电后，其他地区必须能接管服务。这个问题的答案就是使用CCR（Cross-cluster replication）。

CCR提供了一种从主集群（primary cluster）自动同步索引到secondary remote cluster的方法，即secondary remote cluster作为一个热备（hot backup）。如果primary cluster发生了故障，secondary cluster可以进行接管。你可以使用CCR创建secondary cluster，给地理上靠近（geo-proximity）这个secondary cluster的用户提供读取请求。

Care and feeding

与任何企业系统一样，你需要工具来secure，manage，以及monitor你的Elasticsearch 集群。Security，monitoring，以及administrative features都集成到了Elasticsearch，使得你可以使用Kibana作为控制中心来管理集群。比如data rollups、index lifecycle management这些功能能帮助你根据时间来管理你的数据。

Set up Elasticsearch

link

这个章节介绍了如何设置Elasticsearch并且使其运行，包含的内容有：

下载
安装
启动
配置

Supported platforms

官方给出的操作系统以及JVM的支持列表见Support Matrix.Elasticsearch在这些平台上都经过了测试，但是在列表外的其他平台上还是有可能可以正常工作的。

Java（JVM）Version

Elasticsearch使用Java构建，并且每次发布都捆绑了一个OpenJDK，这个OpenJDK由JDK维护者使用GPLv2+CE协议维护。建议使用捆绑的JDK，它位于Elasticsearch home目录中名为jdk的目录中。

可以通过设置环境变量ES_JAVA_HOME来使用你自己的Java版本。如果你一定要使用一个跟捆绑的JVM不一样的Java版本，我们建议你使用Java的长期支持版本LTS 。如果使用了一个错误Java版本的，Elasticsearch将不会启动。当你使用了自己的JVM后，绑定的JVM目录可能会被删除。

Use delicated hosts 使用专用的主机

在生产上，我们建议你在专用的主机或者主服务器上（primary service）运行Elasticsearch。假定Elasticsearch是主机上或者容器上唯一的资源密集型的应用，那么一些Elasticsearch的功能比如自动化分配JVM堆大小就能实现。比如说，你可能同时运行Metribeat跟Elasticsearch来做集群统计，那么就应该将resource-heavy的Logstash部署在它自己的主机上。

Installing Elasticsearch

link

Hosted Elasticsearch

你可以在自己的设备上运行Elasticsearch或者也可以使用AWS, GCP, and Azure上专用的Elasticsearch服务器。

Installing Elasticsearch Yourself

Elasticsearch以下列的打包方式呈现：

Configuration Management Tools

我们同样提供了下列的配置管理工具有助于大型的部署

Install Elasticsearch from archive on Linux or MacOS

link

在Linux和MacOS平台下，Elasticsearch是作为一个.tar.gz的归档文件。

这个安装包同时包含了免费和订阅的特性，30天试用可以使用所有的功能。

Elasticsearch最新的稳定版本可以从这个页面下载，其他版本可以从过去的发布页面下载。

NOTE： Elasticsearch中捆绑了一个OpenJDK，这个OpenJDK由JDK维护者使用GPLv2+CE协议维护，如果要使用自己的Java版本,

Download and install archive for Linux

Linux下Elasticsearch-7.15.2归档文件的下载以及安装如下所示：


1
wget https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-7.15.2-linux-x86_64.tar.gz
2
wget https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-7.15.2-linux-x86_64.tar.gz.sha512
3
shasum -a 512 -c elasticsearch-7.15.2-linux-x86_64.tar.gz.sha512 
4
tar -xzf elasticsearch-7.15.2-linux-x86_64.tar.gz
5
cd elasticsearch-7.15.2/

上文第三行Compares the SHA of the downloaded .tar.gz archive and the published checksum，which should output elasticsearch-{version}-linux-x86_64.tar.gz: OK。

上文第五行就是所谓的 $ES_HOME。

Download and install archive for MacOS

MacOS下Elasticsearch-7.15.2归档文件的下载以及安装如下所示：


xxxxxxxxxx
5
1
wget https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-7.15.2-darwin-x86_64.tar.gz
2
wget https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-7.15.2-darwin-x86_64.tar.gz.sha512
3
shasum -a 512 -c elasticsearch-7.15.2-darwin-x86_64.tar.gz.sha512 
4
tar -xzf elasticsearch-7.15.2-darwin-x86_64.tar.gz
5
cd elasticsearch-7.15.2/

上文第三行Compares the SHA of the downloaded .tar.gz archive and the published checksum，which should output elasticsearch-{version}-linux-x86_64.tar.gz: OK。

上文第五行就是所谓的 $ES_HOME。

Enable automatic creation of system indices

一些商业功能会自动创建索引。默认情况下，Elasticsearch可以被配置为允许自动创建索引，并且不需要再做额外的步骤。然而，如果你关闭了自动创建索引，你必须在elasticsearch.yml中配置action.auto_create_index来允许商业功能创建下面的索引：


xxxxxxxxxx
1
1
action.auto_create_index: .monitoring*,.watches,.triggered_watches,.watcher-history*,.ml*

IMPORTANT：如果你正在使用Logstash或者Beats，那么你很有可能需要在action.auto_create_index配置额外的索引名，确切的名称取决去你的本地配置。如果你不能保证正确的名称，你可以考虑将索引名设置为*，这样就会自动创建所有的索引

Running Elasticsearch from the command line

Elasticsearch可以通过下面的命令行启动：


xxxxxxxxxx
1
1
./bin/elasticsearch

如果Elasticsearch keystore有密码保护，你会被提示（be prompted to）输入keystore's的密码，详细内容见安全配置。

默认情况下，Elasticsearch将日志打印到控制台（标准输出）以及日志目录的<clustername>.log文件中。Elasticsearch在启动期间会生成一些日志，但一旦初始化完成，它将继续在前台（foreground）运行并且不再生成任何日志直到一些值的记录的信息产生。在Elasticsearch运行期间，你可以通过HTTP接口访问默认的9200端口与Elasticsearch交互。输入Ctrl-c来停止Elasticsearch。

NOTE：Elasticsearch安装包中的所有脚本要求的Bash版本需要支持arrays并且假定/bin/bash是存在的，同样的，Bash在这个路径是存在的或者能通过动态链接找到

Checking that Elasticsearch is running

你能通过HTTP请求访问localhost:9200来测试Elasticsearch节点是否在运行中：


xxxxxxxxxx
1
1
GET /

你应该能收到类似下面的回应（response）


xxxxxxxxxx
17
1
{
2
  "name" : "Cp8oag6",
3
  "cluster_name" : "elasticsearch",
4
  "cluster_uuid" : "AT69_T_DTp-1qgIJlatQqA",
5
  "version" : {
6
    "number" : "7.15.2",
7
    "build_flavor" : "default",
8
    "build_type" : "tar",
9
    "build_hash" : "f27399d",
10
    "build_date" : "2016-03-30T09:51:41.449Z",
11
    "build_snapshot" : false,
12
    "lucene_version" : "8.9.0",
13
    "minimum_wire_compatibility_version" : "1.2.3",
14
    "minimum_index_compatibility_version" : "1.2.3"
15
  },
16
  "tagline" : "You Know, for Search"
17
}

Running as a daemon

在命令行指定-d使得Elasticsearch成为一个后台程序，并且通过参数-p生成一个pid文件记录进程号。


xxxxxxxxxx
1
1
./bin/elasticsearch -d -p pid

如果Elasticsearch keystore有密码保护，你会被提示（be prompted to）输入keystore's的密码，详细内容见安全配置。

在$ES_HOME/logs/目录能找到日志信息。

通过杀死pid文件中记录的进程号来关闭Elasticsearch。


xxxxxxxxxx
1
1
pkill -F pid

NOTE：tar.gz的安装包中不包含systemd组件。如果要把Elasticsearch作为一个服务管理，用RPM或者Debian的安装包进行安装。

Configuring Elasticsearch on the command line

Elasticsearch默认装载(load)的配置文件路径为$ES_HOME/config/elasticsearch.yml，这个配置文件中的格式见Configuring Elasticsearch。

在配置文件中可以指定的任何设置（settings）都可以通过命令行的参数指定，使用-E语法：


xxxxxxxxxx
1
1
./bin/elasticsearch -d -Ecluster.name=my_cluster -Enode.name=node_1

TIP：一般来说，任何集群范围（cluster-wide）的配置（比如说 cluster.name）都应该在elasticsearch.yml文件中配置，同时具体节点的任意配置比如说node.name可以通过命令行参数指定

Directory layout of archives

归档发行版 (archive distribution)是self-contained（意思就是所有的文件都在同一个目录中，Elasticsearch还有安装包发行版package distribution，通过这种方式安装后，文件会分散在不同的目录中）。所有的文件和目录默认情况下都在$ES_HOME下，$ES_HOME在解压归档后会被创建。

这是一种非常方便的方式因为你不需要创建任何目录来开始使用Elasticsearch，并且当卸载Elasticsearch时只要简单的移除$ES_HOME。然而我们建议把配置文件目录config directory、数据目录data directory、以及日志目录log directory的位置进行变更，以免在以后重要的数据被删除。

类型Type	描述Description	默认位置Default Location	设置Setting
home	Elasticsearch home目录或者`$ES_HOME`	解压归档后创建这个目录
bin	二进制脚本，包含`elasticsearch`用于启动一个节点以及`elasticsearch-plugin`用于安装插件	`$ES_HOME/bin`	ES_PATH_CONF
conf	包含`elasticsearch.yml`的所有配置文件	`$ES_HOME/config`
data	每一个索引/分片的数据文件的位置	`$ES_HOME/data`	path.data
logs	日志文件位置	`$ES_HOME/logs`	path.logs
plugins	插件文件位置。每个插件在一个子目录中	`$ES_HOME/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.	NOT_configured	path.repo

Next steps

现在你建好了一个Elasticsearch测试环境。在你开始认真做开发护着进入Elasticsearch的生产环境，你必须做一些额外的设置：

学习如何配置Elasticsearch
配置重要的Elasticsearch设置
配置重要的系统设置

Install Elasticsearch with Docker

link

Configuring Elasticsearch

（8.2）link

Elasticsearch附带（ship with）了很好的默认配置并且只需要较小的配置。在一个运行中的集群中，大部分的设置可以通过Cluster update settings API进行更改。

配置文件应该包含对指定节点（node-specific）的设置，例如node.name以及路径，或者是能让节点加入集群的配置，例如cluster.name以及network.host。

Config files location

Elasticsearch有三个配置文件：

elasticsearch.yml 用于配置 Elasticsearch
jvm.options 用于配置Elasticsearch JVM 设置
log4j2.properties 用于配置 Elasticsearch日志记录

这三个文件都在config目录中，它们的默认路径取决于使用哪种方式安装：归档发行版（archive distribution）tar.gz或者zip还是安装包发行版（package distribution）Debian 或者RPM安装包。

对于归档发行版，config目录位置默认是$ES_HOME/config。config目录的位置能通过ES_PATH_CONFIG这个环境变量进行更改：


xxxxxxxxxx
1
1
ES_PATH_CONF=/path/to/my/config ./bin/elasticsearch

或者，通过在命令行或profile文件中export ES_PATH_CONFIG这个环境变量。

对于安装包发行版，config目录的位置默认在/etc/elasticsearch，config目录的位置可以通过ES_PATH_CONF这个环境变量变更。注意的是在shell中设置这些是不够的。Instead, this variable is sourced from /etc/default/elasticsearch (for the Debian package) and /etc/sysconfig/elasticsearch (for the RPM package). You will need to edit theES_PATH_CONF=/etc/elasticsearch entry in one of these files accordingly to change the config directory location.

Config file format

配置格式是YAML，下面是更改数据和日志目录的例子


xxxxxxxxxx
3
1
path:
2
    data: /var/lib/elasticsearch
3
    logs: /var/log/elasticsearch

配置也可以进行平铺（flattened）


xxxxxxxxxx
2
1
path.data: /var/lib/elasticsearch
2
path.logs: /var/log/elasticsearch

在YAML中，你可以格式化non-scalar的值写成序列：


xxxxxxxxxx
4
1
discovery.seed_hosts:
2
   - 192.168.1.10:9300
3
   - 192.168.1.11
4
   - seeds.mydomain.com

尽管下面的方式不是很常见（Thought less common），你也可以把non-scala的值写成数组：


xxxxxxxxxx
1
1
discovery.seed_hosts: ["192.168.1.10:9300", "192.168.1.11", "seeds.mydomain.com"]

Environment variable substitution

在配置文件中可以通过使用${...}这类符号的方式引用环境变量：


xxxxxxxxxx
2
1
node.name:    ${HOSTNAME}
2
network.host: ${ES_NETWORK_HOST}

环境变量的值必须是简单的String值，用逗号分隔的String值会被Elasticsearch解析成一个list。例如，Elasticsearch将下面的环境变量的String值根据逗号切分到list中。


xxxxxxxxxx
1
1
export HOSTNAME="host1,host2"

Cluster and node setting types

集群跟节点的设置基于它们是如何被配置可以分类为：

Dynamic（settings）

在一个正在运行的集群上，你可以使用cluster update settings API来配置或更新动态设置。你也可以使用elasticsearch.yml对本地未启动或者关闭的节点配置动态设置。

使用cluster update settings API更新可以是永久的（persistent），即使集群重启也生效，也可以是临时的（transient），集群在重启后就重置了。你也可以通过使用API把配置设置为null也能重置使用persistent或者transient更新过的设置。

如果你用多种方式配置了一样的设置，那么Elasticsearch会根据下面的优先顺序（order of precedence）来应用设置（apply settings）。

Transient Setting
Persistent Setting
elasticsearch.yml setting
Default setting value

例如，你可以使用一个transient setting覆盖persistent setting或者elasticsearch.yml。然而，在elasticsearch.yml上的变更不会覆盖定义好的（defined）transient 或者 persistent setting。

TIP：如果你使用Elasticsearch Service，使用user settings功能来配置所有的设置。这个方法能让Elasticsearch自动的拒绝（reject）掉任何会破坏你集群的设置。如果你在自己的设备（hardware）上运行Elasticsearch，可以使用cluster update settings API来配置集群动态设置。对于集群或者节点的静态设置只使用elasticsearch.yml来配置。使用API不会要求重启并且保证所有节点都被配置成相同的值。

WARNING: We no longer recommend using transient cluster settings. Use persistent cluster settings instead. If a cluster becomes unstable, transient settings can clear unexpectedly, resulting in a potentially undesired cluster configuration. See the Transient settings migration guide.

Static（settings）

静态设置只能在未启动或者关闭的节点上使用elasticsearch.yml来配置。

静态配置必须在集群中相关的所有节点上一一配置。

Important Elasticsearch configuration

（8.2）link

Elasticsearch只需要很少的配置就能启动。但是在生产中使用你的集群时必须要考虑这些条目：

我们的Elastic Cloud service能自动配置这些条目，使得你的集群处在生产就绪状态。

Path settings

Elasticsearch把你的索引数据和数据流（data streams）都写到data目录中。

Elasticsearch本身也会生产应用日志，包含集群健康信息以及集群操作信息，并且写入到logs目录中。

对于在MacOS和Linux下使用.tar.gz, 以及Windows下使用zip方式安装时，data和logs目录默认是$ES_HOME下的子目录，然而在升级Elasticsearch时，位于$ES_HOME下的文件是存在风险的。

在生产中，我们强烈建议在elasticsearch.yml中设置path.data和path.logs将data和logs目录放到$ES_HOME以外的位置。其他安装方式（rpm、macOS Homebrew、Windows .msi）默认会把data和logs目录放到$ES_HOME以外的位置。

支持在不同的平台，path.data和path.logs可以是不同的值：

Unix-like systems
- Linux and macOS installations support Unix-style paths:


xxxxxxxxxx
3
1
path:
2
  data: /var/data/elasticsearch
3
  logs: /var/log/elasticsearch

Windows
- Windows installations support DOS paths with escaped backslashes:


xxxxxxxxxx
3
1
path:
2
  data: "C:\\Elastic\\Elasticsearch\\data"
3
  logs: "C:\\Elastic\\Elasticsearch\\logs"

WARNING：不要更改data目录中的任何内容（content），也不要运行可能会影响data目录内容的程序。如果Elasticsearch以外的程序更改了data目录的内容，那么Elasticsearch可能会失败，报告损坏或者其他数据不一致性（data inconsistencies）的问题，也可能工作正常但是丢失了一些你的数据。

Multiple data paths

WARNING: 在7.13.0版本中废弃了

如果有这个需要，你可以在path.data中指定多个路径。Elasticsearch会在这些路径上存储节点的数据，但是会在相同的路径上存储同一个shard的数据。

Elasticsearch不会在多个路径上去平衡shards的写入。在某个路径上的高磁盘使用率会触发整个节点的high disk usage watermark。触发后，Elasticsearch不会在这个节点增加shard，尽管这个节点的在其他路径上有可用的空间。如果你需要额外的磁盘空间，我们建议你增加新的节点而不是增加data的路径。

Unix-like systems
- Linux and macOS installations support Unix-style paths:


xxxxxxxxxx
5
1
path:
2
  data:
3
    - /mnt/elasticsearch_1
4
    - /mnt/elasticsearch_2
5
    - /mnt/elasticsearch_3

Windows
- Windows installations support DOS paths with escaped backslashes:


xxxxxxxxxx
5
1
path:
2
  data:
3
    - "C:\\Elastic\\Elasticsearch_1"
4
    - "E:\\Elastic\\Elasticsearch_1"
5
    - "F:\\Elastic\\Elasticsearch_3"

Migrate from multiple data paths

在7.13版本中弃用了多个数据路径的支持，将会在未来的版本中移除。

作为多个数据路径的替代方案，你可以通过使用硬件虚拟化层（如RAID）或软件虚拟化层（如Linux上的逻辑卷管理器（LVM）或Windows上的存储空间）来创建跨多个磁盘的文件系统。如果你希望在单台机器上使用多个数据路径，则必须为每个数据路径运行一个节点。

如果你正在一个highly available cluster中使用多个数据路径，你可以无需停机，使用类似rolling restart的方式对一个节点使用单个数据路径来实现迁移：轮流关闭每一个节点，并用一个或多个配置为使用单个数据路径的节点替换它。跟进一步的说，对于每一个当前有多个数据路径的节点来说，你应该按照下面的步骤进行迁移。原则上你可以在升级到8.0版本时执行这类迁移，但是我们建议在升级版本前先完成单个数据路径的迁移工作。

执行快照防止你的数据出现灾难性的问题
（可选）使用allocation filter将目标节点的数据进行迁移


xxxxxxxxxx
6
1
PUT _cluster/settings
2
{
3
  "persistent": {
4
    "cluster.routing.allocation.exclude._name": "target-node-name"
5
  }
6
}

你可以使用cat allocation API来跟踪数据迁移的进度。如果某些分片没有迁移，那么cluster allocation explain API会帮助你查明原因。

按照rolling restart process中的步骤执行，包括关闭目前节点。
确保你的集群是yellow或者green，使得你的集群中至少有一个节点有每一个分片的拷贝。
如果执行了上面的第二步，现在需要移除allocation filter。


xxxxxxxxxx
6
1
PUT _cluster/settings
2
{
3
  "persistent": {
4
    "cluster.routing.allocation.exclude._name": null
5
  }
6
}

通过删除数据路径的方式来丢弃被停掉的节点拥有的数据。
重新配置你的存储。使用LVM或者Storage Spaces将你的磁盘合并到单个文件系统中。确保你重新配置的存储有足够的空间存储数据
通过设置elasticsearch.yml文件中的path.data来重新配置你的节点。如果有需要的话，安装更多的节点，并使用它们自己各自的path.data。
启动新的节点并按照rolling restart process中的其他步骤执行
确保你的集群健康是green，使得所有的分片都已经分配结束

你也可以在你的集群中增加一些单数据路径的节点，使用allocation filters将你的数据迁移到新的节点中，然后将这些旧的节点从集群中移除。这个方法会临时增大集群中的体积，所以只有你的集群有这个膨胀能力才能使用这个方法。

如果你目前使用多个数据路径，但你的集群并不具备高可用性，则可以通过拍摄快照、创建具有所需配置的新集群并将快照还原到其中来迁移到非废弃配置。

Cluster name setting

在一个集群中，一个节点只有跟集群中的其他节点共享他的cluster.name才能加入到这个集群中。默认的名称是elasticsearch，但是你应该把这个名称改成一个合适的名称，这个名称能描述这个集群的目的。


xxxxxxxxxx
1
1
cluster.name: logging-prod

IMPORTANT：在不同的环境中不要重复使用相同的集群名，否则节点可能会加入到错误的集群中。

Node name setting

Elasticsearch使用node.name作为可读（human-readable）的一个特定的Elasticsearch实例。在很多APIs的返回中（response）会用到。当Elasticsearch启动后，节点名称默认是服务器的hostname，可以在elasticsearch.yml中显示配置：


xxxxxxxxxx
1
1
node.name: prod-data-2

Network host setting

默认清下，Elasticsearch只绑定类似127.0.0.1以及[::1]的回调地址（lookback address）。这样的话能够在单个服务上允许一个集群的多个节点用于开发以及测试。但是一个resilient production cluster必须是包含在其他服务上的节点。尽管还有许多newwork settings，但是通常你只需要配置network.host：


xxxxxxxxxx
1
1
network.host: 192.168.1.10

当你提供了network.host的值，Elasticsearch会假设你正在从开发模式转到生产模式，并且会在系统启动时升级warning到exception的检查。见development and production modes的差异。

Discovery and cluster formation settings(setting)

在进入生产前配置两个重要的discovery和cluster formation设置，使得这个集群中的节点能互相发现并且选出一个master节点。

discovery.seed_hosts

如果没有配置任何网络设置，Elasticsearch会绑定可见的回调地址并且扫描本地的9300到9305端口去连接同一个服务上的其他节点。这种行为提供了一种自动集群体验，而无需进行任何配置。即开箱即用（out of box）。

当你想要组成（form）一个集群，它包含的节点在其他服务器上时，可以使用静态的discovery.seed_hosts设置。这个设置可以提供一个集群中其他节点的list，这些节点是候选的主节点（mater-eligible），并且有可能是live的，并且能在discovery process中作为可以联系的节点来选出种子选手（and contactable to seed the discovery process。翻译能力有限，只可意会，不可言传）。这个设置可以将集群中所有候选的主节点的地址用YAML中的序列或者数组的风格书写。每一个地址可以是IP地址或者hostname，hostname可以通过DNS关联一个或多个IP地址。


xxxxxxxxxx
5
1
discovery.seed_hosts:
2
   - 192.168.1.10:9300
3
   - 192.168.1.11 
4
   - seeds.mydomain.com 
5
   - [0:0:0:0:0:ffff:c0a8:10c]:9301

如果IP地址中没有指定端口号，那么就是默认的9300，默认的端口号也可以被override
如果hostname关联多个IP 地址，那么当前节点会试图发现hostname关联的所有地址上的节点
IPv6地址使用方括号包裹（enclosed in square brackets）

如果候选的主节点的节点没有固定的名称或者地址，可以使用alternative hosts provider 来动态的找到它们的地址。

cluster.initial_master_nodes

当你第一次启动Elasticsearch集群，在cluster bootstrapping阶段确定在第一次参与投票的候选主节点。在development mode中，with no discovery settings configured, this step is performed automatically by the nodes themselves。

因为auto-bootstrapping是内在不安全的，在生产模式中启动一个新的集群时，你必须显式列出候选的主节点并且它们的投票要被统计在第一轮的选票中。你可以使用cluster.initial_master_nodes设置来列出这些候选的主节点。

IMPORTANT：当一个新的集群第一次形成之后，从每个节点的配置中移除cluster.initial_master_nodes设置。当重启一个集群或者往已存在的集群中添加一个新的节点时，不要使用该配置。


xxxxxxxxxx
9
1
discovery.seed_hosts:
2
   - 192.168.1.10:9300
3
   - 192.168.1.11
4
   - seeds.mydomain.com
5
   - [0:0:0:0:0:ffff:c0a8:10c]:9301
6
cluster.initial_master_nodes: 
7
   - master-node-a
8
   - master-node-b
9
   - master-node-c

通过node.name来确定最初的master节点身份，默认是hostname。要确保cluster.initial_master_nodes跟node.name的值是一致的。如果节点的名称使用了全限定域名（fully-qualified domain name），比如master-node-a.example.com，那么你必须在cluster.initial_master_nodes中使用FQDN。相反的，如果只是仅仅使用了hostname而没有尾随的限定符，那么在cluster.initial_master_nodes也不能带尾随的限定符

见 bootstrapping a cluster和discovery and cluster formation settings。

Heap size settings

默认情况下，Elasticsearch会根据节点的roles跟内存大小来自动的设置JVM堆的大小。我们建议使用默认的大小，它适用于大部分生产环境。

NOTE：堆大小的自动配置需要bundle JDK，如果使用自定义的JRE位置，需要Java 14以及更新的JRE。

如果有必要，你可以通过setting the JVM heap size手动覆盖默认值。

JVM heap dump path setting

默认情况下，Elasticsearch会配置JVM，使得OOM异常转存（dump）到data目录。在基于ROM跟Debian的安装包中，data目录位于/var/lib/elasticsearch。在Linux、MacOs以及Windows发行版中，data目录位于Elasticsearch安装目录的根目录。

如果默认的路径用于接受heap dump不是很合适，那么可以通过在文件jvm.options中修改-XX:HeapDumpPath=...。

如果你指定了一个目录，JVM将会基于正在运行的实例，用它的PID来为heap dump文件命名
如果你指定了一个固定的文件名而不是一个目录，那么这个文件必须不存在，否则heap dump会失败

GC logging settings

默认情况下，Elasticsearch开启了垃圾回收日志。在jvm.options文件中配置，并且输出到Elasticsearch的logs文件中。默认的配置中，每64M就会轮换一次日志，最多消耗2G的磁盘空间。

你可以命令行来配置JVM的日志打印，见JEP 158: Unified JVM Logging。除非你直接更改jvm.options文件，Elasticsearch的默认配置会被应用（apply）除了你自己的设置。如果要关闭默认配置，第一步先通过提供参数-Xlog:disable关闭日志打印，然后提供你自己的命令选项。以上操作会关闭所有的JVM日志打印，所以要确定好可用的选项来满足你的需求。

见 Enable Logging with the JVM Unified Logging Framework了解更多在原始的JEP（origin JEP）中不包含的虚拟机选项。

Examples

下面的例子中创建了$ES_HOME/config/jvm.options.d/gc.options并包含一些虚拟机选项：把默认的GC 日志输出到/opt/my-app/gc.log。


x
1
# Turn off all previous logging configuratons
2
-Xlog:disable
3

4
# Default settings from JEP 158, but with `utctime` instead of `uptime` to match the next line
5
-Xlog:all=warning:stderr:utctime,level,tags
6

7
# Enable GC logging to a custom location with a variety of options
8
-Xlog:gc*,gc+age=trace,safepoint:file=/opt/my-app/gc.log:utctime,pid,tags:filecount=32,filesize=64m

下面的例子中配置一个Elasticsearch Docker container，将GC的debug日志输出到stderr，让容器编排器处理输出。


xxxxxxxxxx
2
1
MY_OPTS="-Xlog:disable -Xlog:all=warning:stderr:utctime,level,tags -Xlog:gc=debug:stderr:utctime"
2
docker run -e ES_JAVA_OPTS="$MY_OPTS"

Temporary directory settings

默认情况下，Elasticsearch会使用一个私有的临时目录，它由一个启动脚本创建，并位于系统的临时目录中。

在一些Linux发行版中，一些系统工具会清楚 /tmp 目录下长时间未被访问的文件。这会导致Elasticsearch的私有临时目录可能会被删除。移除私有的临时目录会导致一些问题，比如一些功能随后会访问这些私有临时目录。

如果你使用.deb或者.rpm安装的Elasticsearch，并且在systemd下运行，那么Elasticsearch使用的私有临时目录不会被周期性的清除（periodic cleanup）。

如果你想要在Linux跟MacOS上运行.tar.gz发行版，可以考虑为Elasticsearch创建一个专用的临时目录，并且该目录所在路径中不包含旧的文件或目录，并且这个目录只有Elasticsearch有访问权限。最后在Elasticsearch启动前设置环境变量$ES_TMPDIR。

JVM fatal error log setting

默认情况下，Elasticsearch会配置JVM将fatal错误日志写到默认的日志目录中。在RPM和Debian安装中，目录位置为/var/log/elasticsearch，在Linux、MacOs、Windows发行版中，logs目录位于Elasticsearch的安装目录。

当遇到一些fatal错误日志，它由JVM产生，比如说段错误（segmentation fault）。如果接受这些日志的路径不是很合适，可以在jvm.options中修改-XX:ErrorFile=...。

Cluster backups

在发生灾难时，snapshot能防止数据永久丢失。Snapshot lifecycle management是最简单的办法来对集群实现定期备份。见Create a snapshot。

WARNING：快照是唯一可靠并且被支持的方式（supported way）来备份集群。你不能通过拷贝data目录中的节点数据进行备份。没有一种支持方式（supported way）从文件系统层面的备份来恢复数据。如果你想尝试从这种备份中恢复集群，可能会失败并且Report出corruption或者文件丢失或者其他数据一致性的问题，或者出现成功的悄无声息的丢失一些你的数据

Secure settings

（8.2）link

有些设置是敏感的（sensitive），仅仅依靠文件系统的权限来保护这些值是不够。对于这种情况，Elasticsearch提供了keystore和 elasticsearch-keystore tool 来管理这些设置。

IMPORTANT：只有一些设置被设计为从keystore中读取。但是keystore没有验证一些不支持的设置。增加不支持的设置会导致Elasticsearch启动失败。

所有在keystore中的变更只有在Elasticsearch重启后才生效。

keystore中设置跟配置文件elasticsearch.yml中的普通的设置项一样都需要在每个节点上指定。当前，所有的安全设置都是特定于节点的，即所有的节点上必须设置相同的值。

Reloadable secure settings

跟elasticsearch.yml中的设置值一样，keystore中的内容无法自动的应用（apply）到正在运行的Elasticsearch节点，需要重启。然而有一些安全设置被标记为reloadable，这些设置可以被reload。

对于安全设置的值，不管是否可以reloadable，集群中的所有节点都必须一致。在安全设置变更后，执行bin/elasticsearch-keystore调用下面的请求：


xxxxxxxxxx
4
1
POST _nodes/reload_secure_settings
2
{
3
  "secure_settings_password": "keystore-password" 
4
}

Elasticsearch keystore会对密码进行加密。

上述API会解密并且重新读取集群中所有节点的整个keystore，但是只有reloadable的安全设置可以被应用（apply）。其他的安全设置不会生效直到下一次重启。一旦API调用返回了，意味着reload完成了，即所以依赖这些设置的内部数据结构都已经发生了变更。Everything should look as if the settings had the new value from the start。

当更改了多个reloadable安全设置后，在集群中的每一个节点上修改后，随后发起reload_secure_settings的调用，而不用在每一次变更后reload。

下面是reloadable安全设置

Auditing security settings

（8.2）link

你可以使用audit logging来记录安全相关的事件，比如认证失败，拒绝连接，以及数据访问事件。另外也会记录通过API访问安全配置的操作，例如创建、更新、移除native、built-in users，roles、role mappings 以及 API keys。

TIP：日志审计只在某些订阅中提供，详细信息见 https://www.elastic.co/subscriptions

在配置后，集群上的所有节点都需要设置一遍。静态设置，比如说xpack.security.audit.enabled，在每个节点的elasticsearch.yml中都必须配置。对于动态的日志设置，使用cluster update settings API 可以让所有节点的设置一致。

General Auditing Settings

xpack.security.audit.enabled

（Static）设置为true来开启。默认值为false。在每个节点上日志事件会被放到一个名为<clustername>_audit.json的专用的文件中。

如果开启了，集群中的所有节点的elasticsearch.yml都需要配置该设置。

Audited Event Settings

日志事件以及其他一些信息比如获取什么样的日志可以通过下面的设置来控制：

xpack.security.audit.logfile.events.include

（Dynamic）在日志输出中指定事件类型（kind of events），设置为_all会彻底的记录所有的日志事件，但通常不建议这么做因为会非常的verbose。默认值是一个list包含：access_denied, access_granted, anonymous_access_denied, authentication_failed, connection_denied, tampered_request, run_as_denied, run_as_granted, security_config_change。

xpack.security.audit.logfile.events.exclude

（Dynamic）从包含的（kind of events）列表中指定排除部分选项。当xpack.security.audit.logfile.events.include的值设置为_all时，然后用xpack.security.audit.logfile.events.exclude来进行指定选项的排除是不错的方式。默认值是空的list。

xpack.security.audit.logfile.events.emit_request_body

（Dynamic）用于指定是否将REST请求的请求body作为日志事件的属性，这个设置可以用于audit search queries。

默认是false，那么请求body不会被打印出来。

IMPORTANT：注意的是，当日志事件中包含请求body时，一些敏感数据可能以明文形式被记录，即使是一些安全相关API，比如修改用户密码，认证信息在开启后有被泄露（filter out）的风险

Local Node Info Settings

xpack.security.audit.logfile.emit_node_name

（Dynamic）指定在每一个日志事件中，节点名称node name是否作为其中的一个字段。默认值是false。

xpack.security.audit.logfile.emit_node_host_address

（Dynamic）指定在每一个日志事件中，节点的地址是否作为其中的一个字段。默认值是false。

xpack.security.audit.logfile.emit_node_host_name

（Dynamic）指定在每一个日志事件中，节点的主机名是否作为其中的一个字段。默认值是false。

xpack.security.audit.logfile.emit_node_id

（Dynamic）指定在每一个日志事件中，节点的id是否作为其中的一个字段。不同于node name，管理员可以在配置文件中修改节点id，节点id在集群启动后将不可变更，默认值是true。

Audit Logfile Event Ignore Policies

下面的设置会影响ignore policies，它们能更精细的（fine-grained）控制日志事件打印到日志文件中。拥有相同police_name的设置将会组合到一个策略（police）中。如何一个事件匹配到任意一条策略的所有条件，该日志事件将被忽略并不会被打印。大多数的日志事件都遵照（subject to）忽略策略。唯一的例外（sole exception）是security_config_change类型的事件，无法被过滤掉（filter out），除非完全的通过xpack.security.audit.logfile.events.exclude进行exclude。

xpack.security.audit.logfile.events.ignore_filters.<policy_name>.users

（Dynamic）用户名称列表或者名称通配值（wildcards）。匹配该值的所有用户的日志事件不会打印出来。

xpack.security.audit.logfile.events.ignore_filters.<policy_name>.realms

（Dynamic）authentication realm的列表或者通配值，匹配该值的所有realm的日志事件不会打印出来。

xpack.security.audit.logfile.events.ignore_filters.<policy_name>.actions

（Dynamic）action名称的列表或者通配值，action的名称可以在日志事件的action字段中找到，匹配该值的所有action的日志事件不会打印出来。

xpack.security.audit.logfile.events.ignore_filters.<policy_name>.roles

（Dynamic）角色列表或者角色通配值（wildcards）。匹配该值并且拥有该角色的所有用户的日志事件不会打印出来。如果用户拥有多个角色，而一些角色没有被策略覆盖到，那么该策略不会覆盖其日志事件。

xpack.security.audit.logfile.events.ignore_filters.<policy_name>.indices

（Dynamic）索引名称列表或者通配值，日志事件中所有的索引名都匹配后才不会打印。如果事件中涉及（concern）了多条索引，并且一些索引没有被该策略覆盖到，那么该策略不会覆盖日志事件。

Circuit breaker settings

（8.2）link

Elasticsearch包含多种熔断器来防止导致OOM的操作。每一种熔断器指定了内存的使用限制。另外，父级别的熔断器指定了内存的总量，限制子级别的熔断器的内存使用总量。

除了特别的说明，这些设置能通过cluster-update-settings API在运行中的集群上进行动态的更新。

关于熔断器提供的报错信息，见Circuit breaker errors。

Parent circuit breaker

父级别的熔断器可以通过下面的设置进行配置：

indices.breaker.total.use_real_memory

（Static）如果该值为true，那么父级别的熔断器会考虑实际的内存使用量，否则考虑的是子级别的熔断器预定（reserved）的内存量总和。默认值为true。

indices.breaker.total.limit

（Dynamic）当indices.breaker.total.use_real_memory为false，并且虚拟机的内存使用量达到70%，或者当indices.breaker.total.use_real_memory为true时，并且虚拟机的内存使用量达到95%，所有的父熔断器开始限制内存使用。

Field data circuit breaker

Filed data熔断器会估算把字段filed载入到field data cache所使用的堆内存量。如果载入后会导致缓存超过了先前定义的内存限制值，熔断器将会停止该操作并返回错误。

indices.breaker.fielddata.limit

（Dynamic）fielddata breaker的限制值，默认是40%的JVM堆内存量。

indices.breaker.fielddata.overhead

（Dynamic）该配置是一个常量，所有field data的估算值乘以这个常量来计算出最终的估算值。默认是值1.03。

Request circuit breaker

Request熔断器允许Elasticsearch防止每一个请求的数据结构（例如，在一次请求中，聚合计算占用的内存量）超过一定量的内存量。

indices.breaker.request.limit

（Dynamic）Request熔断器的限制值，默认是60%的JVM堆内存量。

indices.breaker.request.overhead

（Dynamic）该配置是一个常量，所有Request的估算值乘以这个常量来计算出最终的估算值。默认是值1。

In flight requests circuit breaker

in flight Request熔断器允许Elasticsearch限制所有在传输或者HTTP层的请求的内存使用量不超过在一个节点上的相对内存总量。内存使用量基于请求本身的content length。This circuit breaker also considers that memory is not only needed for representing the raw request but also as a structured object which is reflected by default overhead。

network.breaker.inflight_requests.limit

（Dynamic）in flight Request熔断器的限制值，默认是60%的JVM堆内存量。

network.breaker.inflight_requests.overhead

（Dynamic）该配置是一个常量，所有in flight Request的估算值乘以这个常量来计算出最终的估算值。默认是值2。

Accounting requests circuit breaker

accounting熔断器允许Elasticsearch限制某些请求已经结束，但是相关内存还未被释放的内存量。比如说Lucene的段占用的内存。

indices.breaker.accounting.limit

（Dynamic）accounting熔断器的限制值，默认是100%的JVM堆内存量。这意味着受到父级熔断器的配置限制。

indices.breaker.accounting.overhead

（Dynamic）该配置是一个常量，所有accounting Request的估算值乘以这个常量来计算出最终的估算值。默认是值1。

Script compilation circuit breaker

和上文中的熔断器稍微不同的是，Script compilation熔断器限制了在一个时间周期内inline script compilation的数量。

见scripting 文档中prefer-parameters章节的内容来了解更多。

script.max_compilations_rate

（Dynamic）Limit for the number of unique dynamic scripts within a certain interval that are allowed to be compiled. Defaults to 150/5m, meaning 150 every 5 minutes。

Regex circuit breaker

写的不好的正则表达式会降低（degrade）集群稳定性以及性能。regex熔断器限制了Painless scripts中正则表达式的使用以及复杂性。

script.painless.regex.enabled

（Static)）允许painless脚本中使用正则表达式，该值可以是：

limited（默认值）
- 允许使用正则表达式但是使用集群设置中的script.painless.regex.limit-factor限制正则表达式的复杂性
true
- 允许使用正则表达式并且不限制正则表达式的复杂性。regex熔断器关闭
false
- 不允许使用正则表达式。包含任何正则表达式的painless脚本都会返回错误

script.painless.regex.limit-factor

（Static)）用来限制painless脚本中正则表达式的字符数量。Elasticsearch通过当前设置的值与脚本输入的值的长度的乘积值作为限制值。

比如说输入值foobarbaz的长度为9，如果script.painless.regex.limit-factor的值为6，那么基于foobarbaz的正则表达式的长度为54（6 * 9）。如果超过这个限制值，将触发regex熔断器并返回错误。

只有script.painless.regex.enabled为limited时，Elasticsearch才会使用该限制值。

Cluster-level shard allocation and routing settings

（8.2）link

Shard allocation说的是分配分片到节点的过程。该过程会在initial recovery、副本（replica）分配、rebalancing或者增加或者移除节点时发生。

master node的其中一个应用是决定如何分配分片到节点，何时在节点之间移动分片来平衡集群。

以下的一些设置用来控制分配分片的过程：

Cluster-level shard allocation settings用来控制分片和平衡操作
Disk-based shard allocation settings描述了Elasticsearch如何考虑（take into account）磁盘空间等等相关信息
Shard allocation awareness 和Forced awareness用来控制在不同的rack和可见区域上发布分片
Cluster-level shard allocation filtering允许一些节点或者组内的节点不会被分配分片，使得这些节点能够被关闭（decommissioned）

除此之外，还有一些其他的配置，见Miscellaneous cluster settings。

Cluster-level shard allocation settings

你可以使用下面的设置来控制分片的分配以及恢复：

cluster.routing.allocation.enable

（Dynamic）开启或者关闭某些分片类型的分配：

all：（default）所有类型的分配都可以被分配
primaries：只有主分片才能被分配
new_primaries：只有主分片中新的索引才能被分配
none：任何分片中的任何索引都不能被分配

在节点重启后，上述的配置不会影响本地主分片的恢复。重启后的节点上的未分配的主分片的allocation id如果匹配了集群状态中的active allocation ids，那么会立即恢复。

cluster.routing.allocation.node_concurrent_incoming_recoveries

（Dynamic）在一个节点上允许同时进行恢复incoming recoveries的并发数量。incoming recoveries中的分片（大多数是副本分片或者就是分片正在重新分配位置relocating）将被分配到当前节点上。默认值是2。

cluster.routing.allocation.node_concurrent_outgoing_recoveries

（Dynamic）在一个节点上允许同时进行恢复outgoing recoveries的并发数量。outgoing recoveries中的分片（大多数是当前节点上的主分片或者就是分片正在重新分配位置relocating）将被分配到当前节点上。默认值是2。

cluster.routing.allocation.node_concurrent_recoveries

（Dynamic）一种快捷方法shortcut来设置cluster.routing.allocation.node_concurrent_incoming_recoveries和cluster.routing.allocation.node_concurrent_outgoing_recoveries。

cluster.routing.allocation.node_initial_primaries_recoveries

（Dynamic）在一个节点重启后，副本分片replica的恢复是通过网络实现的，然而一个未分配的主分片unassigned primary则是通过读取本地磁盘数据恢复的。在同一个节点上通过这种本地恢复的方式是很快的，默认值是4。

cluster.routing.allocation.same_shard.host

（Dynamic）该值允许执行一个检查，防止在单个主机上上分配多个相同的分片，通过主机名以及主机地址来描述一台主机。默认值是false。意味着默认不会进行检查。只有在同一台机器上的多个节点启动后，该值才会应用（apply）。

Shard rebalancing settings

当每一个节点上的分片数量是相等并且在任何节点的任何索引上没有集中分片（concentration of shards），那么集群是平衡的。Elasticsearch会运行一个自动程序（automatic process）称为rebalancing，它会在集群中的节点之间移动分片来提高平衡性。rebalancing遵守类似 allocation filtering 和 forced awareness的分片分配规则。这些规则会阻止完全的平衡集群，因此rebalancing会努力（strive to）在你配置的规则下尽可能的去平衡集群。如果你正在使用 data tiers，那么Elasticsearch会自动的应用分配过滤规则将每一个分配放到合适的数据层，这些规则意味着平衡器在每一层中独立工作。

你可以使用下面的设置在集群中控制分片的平衡：

cluster.routing.rebalance.enable

（Dynamic）为指定的分片类型开启或关闭rebalancing：

all：（default）所有类型的分片都允许rebalancing
primaries：只有主分片才允许rebalancing
replicas：只有副本分片才允许rebalancing
none：任何类型分片的任何索引都不允许rebalancing

cluster.routing.allocation.allow_rebalance

（Dynamic）用于指定什么时候允许分片rebalancing

always：总是允许rebalancing
indices_primaries_active：只有当集群中的所有主分片都被分配后
indices_all_active：（default）只有当集群中所有的分片（primaries and replicas）都被分配后

cluster.routing.allocation.cluster_concurrent_rebalance

（Dynamic）用于控制集群范围（cluster wide）内分片平衡并发数，默认值是2。注意的是这个设置仅仅控制因为集群不平衡导致的分片重定位（shard relocating）的并发数。这个设置不会限制因 allocation filtering 和 forced awareness导致的分片重定位。

Shard balancing heuristics settings

基于每个节点上分片的分配情况计算出一个weight来实现rebalancing，并且通过在节点之间移动分片来降低heavier节点的weight并且提高lighter节点的weight。当不存在可能使任何节点的权值与其他节点的权值更接近超过可配置阈值的分片移动时，集群是平衡的。下面的设置允许你控制计算的细节

cluster.routing.allocation.balance.shard

（Dynamic）为节点上分配的分片总数定义一个weight因子。默认值是0.45f。提高这个值会使集群中所有节点的分片数量趋于均衡。

cluster.routing.allocation.balance.index

（Dynamic）为每一个索引的分片数量定义一个weight因子。默认值是0.55f。提高这个值会使集群中所有节点上的每一个索引的的分片数量趋于均衡。

cluster.routing.allocation.balance.threshold

（Dynamic）该值时候一个非负的浮点之后，Minimal optimization value of operations that should be performed。提高这个值将导致集群在优化分片平衡方面不那么积极（leess aggressive）。

NOTE：无论balancing算法的结果如何，rebalancing可能因为forced awareness或者allocation filtering而无法执行

Disk-based shard allocation settings

基于磁盘的分片分配器能保证所有节点都有足够的磁盘空间而不用执行更多的分片移动。它基于一对阈值来分配分片：low wateremark 和 high watermark。主要的目的是保证在每一个节点不会超过high watermark，或者是暂时的超过（overage is temporary）。如果某个节点上超过了high watermark，那么Elasticsearch会通过把分片移动到集群中的其他节点来的方式来解决。

NOTE：节点上有时（from time to time）出现临时的超过high watermark是正常的

分配器总是尝试通过禁止往已经超过low watermark的节点分配更多分配的方式来让节点远离（clear of）high watermark。重要的是，如果所有的节点都已经超过了low watermark那么不会有新的分片会被分配并且Elasticsearch不会通过在节点间移动分片的方式来让磁盘使用率低于high watermark。你必须保证在你的集群中有足够的磁盘空间并且总存在一些低于low watermark的节点。

通过基于磁盘的分片分配器进行的分片移动必须满足（satisfy）其他的分片分配规则，例如 allocation filtering 和 forced awareness。如果这些规则过于严格，它们还可以防止碎片移动，以保持节点的磁盘使用在控制之下。如果你正在使用 data tiers，那么Elasticsearch会自动的应用分配过滤规则将每一个分配放到合适的数据层，这些规则意味着平衡器在每一层中独立工作。

如果某个节点填满磁盘的速度比Elasticsearch将分片移动到其他地方的速度还要快就会有磁盘被填满的风险。为了防止出现这个问题，万不得已的情况下（ as a last resort），一旦磁盘使用达到flood-stage watermark，Elasticsearch会阻塞受到影响的节点上的分片索引的写入。但仍然继续将分片移动到集群中的其他节点。当受到影响的节点上的磁盘使用降到high watermark，Elasticsearch会自动的移除write block。

TIP：集群中的节点各自使用容量不相同的磁盘空间是正常的。集群的balance取决与每一个节点上分片的数量以及分片中的索引。基于下面的两个理由，集群的balance既不会考虑分片的大小，也不会考虑每一个节点上磁盘可用的空间：
磁盘的使用随着时间发生变化。平衡不同节点的磁盘使用将会有很多更多的分片移动，perhaps even wastefully undoing earlier movements。移动一个分片会消耗例如I/O资源以及网络带宽，并且可能从文件系统缓存中换出（evict）数据。这些资源最好用于你的查询和索引。
集群中每一个节点有相同的磁盘使用在性能上通常没有有不同磁盘使用的性能高，只要所有的磁盘不是太满

你可以使用下面的设置控制基于磁盘的分配：

cluster.routing.allocation.disk.threshold_enabled

（Dynamic）默认值为true。设置为false则关闭基于磁盘的分配。

cluster.routing.allocation.disk.watermark.low

（Dynamic）控制磁盘使用量的水位下限（low watermark）。默认值为85%。意味着Elasticsearch不会将分片分配到磁盘使用超过85%的节点上。该值也可以是一个字节单位的值（例如500mb），使得当磁盘空间小于指定的值时就不让Elasticsearch分配分片到这个节点。这个设置不会影响新创建的索引的主分片，但是会组织副本分配的创建。

cluster.routing.allocation.disk.watermark.high

（Dynamic）控制磁盘使用量的水位上限。默认值为90%，意味着Elasticsearch将对磁盘使用量超过90%的节点上的分片进行relocate。该值也可以是一个字节单位的值（跟low watermark类似）。使得当磁盘空间小于指定的值时就把该节点上的分片进行relocate。这个设置会影响所有分片的分配，无论之前是否已经分配。

cluster.routing.allocation.disk.watermark.enable_for_single_data_node

（Static) 在更早的发布中，当做出分配决策时，对于单个数据节点的集群是不会考虑disk watermark的。在7.14之后被值为deprecated并且在8.0移除。现在这个设置唯一合法的值为true。这个设置在未来的发布中移除。

cluster.routing.allocation.disk.watermark.flood_stage

（Dynamic）控制flood stage watermark。只要至少有一个节点超过该值，分配到这个节点的一个或者分片对应的索引会被Elasticsearch强制置为read-only index block（index.blocks.read_only_allow_delete）。这个设置是防止节点发生磁盘空间不足最后的手段。当磁盘使用量降到high watermark后会自动释放index block。

NOTE：你不能在设置中混合使用比例值（percentage）和字节值（byte value）。要么所有的值都是比例值，要么都是字节值。这种强制性的要求使得Elasticsearch可以进行一致性的处理。另外要确保low disk threshold要低于high disk threshold，并且high disk threshold要低于flood stage threshold。

下面的例子中在索引my-index-000001上重新设置read-only index block：


xxxxxxxxxx
4
1
PUT /my-index-000001/_settings
2
{
3
  "index.blocks.read_only_allow_delete": null
4
}

cluster.routing.allocation.disk.watermark.flood_stage.frozen

（Dynamic）用于专用的frozen node，控制flood stage watermark，默认值为95%

cluster.routing.allocation.disk.watermark.flood_stage.frozen.max_headroom

（Dynamic）用于专用的frozen node，控制flood stage watermark的head room。当cluster.routing.allocation.disk.watermark.flood_stage.frozen没有显示设置时默认值为20GB。该值限制（cap）了专用的frozen node上磁盘的空闲量。

cluster.info.update.interval

（Dynamic）Elasticsearch定时检查集群中每一个节点上磁盘使用情况的时间间隔。默认值为30s。

NOTE：比例值说的是（refer to）已使用的磁盘空间，而字节值说的是剩余磁盘空间。这可能会让人疑惑，因为它弄反了高和低的含义。比如，设置low watermark为10GB，high watermark为5GB是合理的，反过来设置的话就不行

下面的例子讲low watermark的值设置为至少100gb，high watermark的值设置为至少50gb，flood stage watermark的值为10gb，并且每一分钟进行检查：


xxxxxxxxxx
9
1
PUT _cluster/settings
2
{
3
  "persistent": {
4
    "cluster.routing.allocation.disk.watermark.low": "100gb",
5
    "cluster.routing.allocation.disk.watermark.high": "50gb",
6
    "cluster.routing.allocation.disk.watermark.flood_stage": "10gb",
7
    "cluster.info.update.interval": "1m"
8
  }
9
}

Shard allocation awareness

你可以自定义节点属性作为感知属性（awareness attributes）让Elasticsearch在分配分片时考虑你物理硬件的配置。如果Elasticsearch知道哪些节点在同一台物理机上、同一个机架（rack）、或者同一个区域，使得在发布主分片跟副本分片时能最低限度的降低丢失所有副本分片的风险。

当使用（Dynamic）的cluster.routing.allocation.awareness.attributes的设置开启awareness attribute后，分片只会被分配到设置了awareness attributes的节点上。当你使用多个awareness attribute时，Elasticsearch在分配分片时会单独地（separately）考虑每一个attribute。

NOTE: attribute values的数量决定了每一个位置上副本分配的分配数量。如果在每一个位置上的节点数量是unbalanced并且有许多的副本，副本分片可能不会被分配

Enabling shard allocation awareness

开启分片的分配awareness，需要：

使用一个自定义的节点属性来指定每个节点的位置。如果你想要Elasticsearch在不同的机架间发布分片，你可能需要在配置文件elasticsearch.yml上设置一个名为rack_id的属性。


xxxxxxxxxx
1
1
node.attr.rack_id: rack_one

你也可以在启动的时候设置自定义的属性。


xxxxxxxxxx
1
1
./bin/elasticsearch -Enode.attr.rack_id=rack_one

在每一个master-eligible node的配置文件elasticsearch.yml上设置cluster.routing.allocation.awareness.attributes，告诉Elasticsearch在分配分片的时候要考虑一个或者多个awareness attribute。


xxxxxxxxxx
1
1
cluster.routing.allocation.awareness.attributes: rack_id

用逗号分隔多个属性。

你也可以使用cluster-update-settings API来设置或者更新集群的awareness attributes。

基于上述的配置例子，如果你启动了两个节点并且都设置node.attr.rack_id为rack_one并且为每个index设置5个主分片，每个主分片设置一个副本分片，那么这两个节点都包含所有的主分片以及副本分片。

如果你增加了两个节点并且都设置node.attr.rack_id为rack_two，Elasticsearch会把分片移动到新的节点，ensuring（if possible）相同的副本分片不会在相同的机架上。

如果rack_two失败并关闭了它的两个节点，默认情况下，Elasticsearch会将丢失的副本分片分配给rack_one中的节点。为了防止特定分片的多个副本被分配到相同的位置，可以启用forced awareness。