前序

文章出自

https://www.elastic.co/guide/en/elasticsearch/reference/current/index.html
文章内容全部出自本人对官方文档的翻译，以及两年多的es使用经验理解，自己理解的部分会特殊标记，无特殊标记处均翻自官网，参考文章时请注意辨别。

正文

路径配置

elasticSearch将索引数据写入索引当中，将数据流写到data目录当中。

elasticSearch将自己的应用日志，包含集群的健康状况、操作信息写入logs的文件中。

在Mac、linux、windows上安装es后，会默认的在ES_HOME目录下创建log、data的子目录，但是文件在ES_HOME下是一件危险的事，如果es进行更新或者卸载时或造成数据丢失。

在生产环境中，强烈建议你自己在elasticSearch.yaml 配置一个path.data和path.log的路径不在ES_HOME下的值。

例子：

path:
  data: /var/data/elasticsearch
  logs: /var/log/elasticsearch

注意：

不要修改数据目录下面的任何文件，也不要运行可能会影响es进程的任何内容。如果一些非es的操作修改了数据文件，会导致es服务的正常运行，es可能会报错，或者出现一些数据的不一致性，也有坑你正常的工作，但是感知不到的丢失了一些重要的数据。不要尝试直接的对数据文件的目录进行备份，没有支持的方法支持这样备份的数据恢复到es中。可以使用快照的方式安全的进行备份。不要尝试使用病毒扫描工具对数据文件进行扫描，病毒扫描工具可能会导致es服务不能正常的进行工作并且有可能修改数据目录中的文件。数据目录中不包含任何可执行的文件，因此扫描工具发现的报警也都是误报。

多数据路径

在7.13.0中被弃用

如果需要的话你可以指定多个路径在path.data中。es会在所有的路径下存储节点的数据，但是每个shard只会存在一个路径下面。

ES是不会垮数据路径来平衡shard的。如果一个磁盘使用率变高则会触发整个节点的磁盘使用率变高的报警，一旦报警触发之后es集群将不会在此节点上分配shard，即便其他磁盘还是哟欧非常多的空闲空间。如果你需要添加磁盘空间，强烈建议你添加一个新节点而不是添加一个新的数据路径。

多数据路径配置：

path:
  data:
    - /mnt/elasticsearch_1
    - /mnt/elasticsearch_2
    - /mnt/elasticsearch_3

个人理解:
	其实这个问题在旧版本的Kafka、旧版本的ES都存在，我们将这种问题称为热点数据问题。
	首先解释一下为什么要配置多数据路径，在linux中多磁盘都是要挂载到多个路径下的，所以想使用多磁盘的性能，肯定不能配置一个路径。
	但如果单节点配置多路径会导致一个问题，ES会轮询的给每个磁盘分配shard但是如果某些shard的数据量大，最后就会导致某一块磁盘满的比较快。
	如果有其中一个磁盘满了，即便别的磁盘还有空间，但是ES就认为这个节点数据存满了。
	所以ES会建议使用单节点单路径，这样就不会出现某块盘存储的是热点的数据的shard，导致这块盘满的比较快，从而浪费其他盘的空闲能力。

多数据路径的迁移

从7.13版本开始，es已经不在支持多数据路径的配置了。
作为多数据路径的替代方案，你可以创建一个拥有多个磁盘但是有一个硬件虚拟化层的文件系统，比如RAID。或者一个软件的虚拟化层，比如linux的LVM或者windows的存储空间。
如果你希望在一个物理的机器上配置多个数据路径，那么你必须为每一个路径开启一个节点。

个人理解:
	最后一句的话意思是，如果物理机是多磁盘的，如果想在7.13版本之后继续使用多磁盘的性能的话，必须在同一台机器上启动多个实例。也就是启动多个es进程，当前也必须有多个ES的服务。相当于将同一个ES_HOME下的所有文件复制多份，但是最后开启的端口不同，来保证每一个路径可以被一个ES服务使用。

如果你当前使用的是一个多数据路径的高可用方案，你可以迁移成单节点单数据路径的模式并且不用停掉ES集群服务，只需要在每个节点上执行关闭节点，修改配置文件，在启动节点的操作即可。具体步骤如下：

1、生成一个快照作为灾备。
2、你可以选择使用分配过滤器将数据迁移到目标节点上。

PUT _cluster/settings
{
  "persistent": {
    "cluster.routing.allocation.exclude._name": "target-node-name"
  }
}

你可以使用查看接口来查询迁移的进度。如果一些分片没有进行迁移，也可以使用集群分配解释API查看失败原因。

3、重复执行上面步骤，滚动的将所有数据路径都迁移到目标节点上。

4、确保集群的状态是黄色或绿色，以便每个shard都有至少一个副本分配到了其他节点。

5、如果可以，删除掉前面创建的分配过滤器。

PUT _cluster/settings
{
  "persistent": {
    "cluster.routing.allocation.exclude._name": null
  }
}

6、删除迁移路径下的数据。

7、重新配置存储。例如使用LVM将多个磁盘合并到一个文件系统中，保证能支持后续的存储使用。

8、通过修改elasticsearch.yml文件中的path.data值来重新配置节点。如果需要可以启动多个ES服务，保证每个节点都有一个单独的数据路径。

9、根据滚动重启的步骤按需启动一些新节点。

10、确定集群状态是green以便所有的shard可以进行重新分配。

你也可以在集群中添加一些只有单路径的节点，然后使用分配过滤的方式将数据迁移到这些新加入的节点上，然后删除掉原有的多路径的节点。这样意味着你的集群规模会临时扩大一倍，当资源允许的情况下可以选择这种方式。

如果你当前使用的是多路径的配置，并且集群不是高可用状态的。你可以同过拍摄一个不带配置的快照，然后创建一个有正确配置的新集群，并在新集群上恢复快照。

集群名配置

一个节点的cluster.name只有和集群的其他节点共享的名字相同的时候才能加入集群，默认情况下集群名为elasticsearch,但是你应该将这个名字修改为一个代表集群含义的名字。

注意:
	不要在不同的环境使用相同的集群名字，这样有可能会导致加入到错误的集群中。

节点名配置

ES使用node.name的值特指es集群中的一个实例。很多的API的响应中都会包含这个值。当ES启动是节点名字的值默认是该节点所在物理机的hostname，也可以在elasticsearch.yml中进行配置。

node.name: prod-data-2

网络地址配置

默认情况下，es会绑定本地的回环地址比如127.0.0.1和[::1]。这样的配置足以保证在一个台机器上启动一个或多个节点组成一个集群来进行开发和测试。但是一个弹性的生产集群是需要配置其他的服务的。es有很多的网络配置，但是一般情况下你只用修改network.hsot:

network.host: 192.168.1.10

重要:
	当你在network.hsot的中配置了一个值的时候，es就会认为你将空开发环境变成了生产环境，并且一些服务启动的检查项会从报警状态更新为异常状态。
个人理解:
	在开发环境时，一些配置不当有可能只是报warning，但是es一旦认定启动的是生产环境，那么这些warning，将会变成error并阻断es服务的正常启动。

集群发现配置

在集群投入生产环境前，配置好发现和集群组成是很重要，以便集群中的节点可以发现其他节点和选择主节点。

discovery.seed_hosts

不需要配置任何网络，开箱即用，es将会绑定本地的回环地址并且扫描9300到9305的端口，去连接其他相似的服务。这个模式下提供了不需要任何配置的自动组建集群的功能。

当你想和其他的节点组成一个集群时，你可以使用静态的discovery.seed_hosts配置。这个配置提供了一个集群中其他节点的列表，包括可以被选为master的节点和处于活跃状态且可以和其他节点联系的节点。配置的内容可以是所有可成为mater节点的IP地址list也可以是yaml格式。所有的地址可以是一个ip也可以是一个能通过dns解析出一个或多个ip地址的域名。

discovery.seed_hosts:
   - 192.168.1.10:9300
   - 192.168.1.11 # 不写时端口默认是 9300，但是也可以像第一个一样进行自定义
   - seeds.mydomain.com  # 如果域名解析出来的ip地址不止一个，此节点会尝试发现解析到的的所有节点
   - [0:0:0:0:0:ffff:c0a8:10c]:9301 # 如果是ipV6格式 则必须使用[]括起来

如果要发现的节点没有一个固定的ip或者地址，你可以使用一个备用的主机作为节点，该节点可以动态的转发到要发现的节点上。

个人理解:
	比如你要发现的节点A的ip不是固定的，你可以使用另外一个可以固定ip的节点B启动一个nginx动态的将es连接的请求转发到要连接点的节点上。这样你如何让节点B知道节点A的IP就可以通过各种手段完成。

cluster.initial_master_nodes

当你第一次启动一个ES集群时，集群的引导程序会从所有具备master的节点中选出票最高的作为主节点。在开发环境下，没有设置节点发现的话，ES默认会选择自己作为主节点。

由于自动的引导程序本质上是不安全的，所以在生产环境启动一个新集群时，一定要明确的指定可成为主节点的列表，用作第一次选主投票使用。

重要:
	当集群已经成功的启动了一次之后，你应该在所有的节点上删除`cluster.initial_master_nodes`这个配置。当时重启集群或者加入节点是不要使用这个配置。

discovery.seed_hosts:
   - 192.168.1.10:9300
   - 192.168.1.11
   - seeds.mydomain.com
   - [0:0:0:0:0:ffff:c0a8:10c]:9301
cluster.initial_master_nodes: 
   - master-node-a
   - master-node-b
   - master-node-c

识别初始的master节点是通过他们的的host.name也就是默认的主机名。确定cluster.initial_master_nodes中的值是各个节点中配置的host.name的值。如果你使用一个全限定域名作为节点名称的话比如master-node-a.example.com，那么在cluster.initial_master_nodes的列表中也必须写全限定域名。当然如果你的host.name没有配置任何后缀，那么在列表中也不能填写后缀。

堆大小配置

默认情况下，ES会自动根据节点角色和内存总大小配置堆的大小。在大多的生产环境中我们建议使用默认的大小。

注意:
	自动配置堆大小需要绑定JDK，如果使用的JRE是本地的JRE，则版本必须大于14.

如果需要你也可以通过手动修改JVM 堆大小配置。

堆转存路径设置

默认情况下，Elasticsearch将JVM配置为在OOM异常时将堆转储到默认数据目录.在RPM和Debain包中，这个数据目录为/var/lib/elasticsearch。在linux、Mac和windows版本中，这个data目录在ES的安装的根目录下。

如果默认的路径不合适用来转存堆数据，那么可以通过-XX:HeapDumpPath=...来修改jvm的选项

- 如果指定了一个目录，那么在JVM将会根据运行的pid和实例在目录下创建文件
- 如果指定的是一个文件，那么在JVM发生OOM需要转存数据时，这个文件一定不能存在，否则的话堆转存将会失败。

GC日志配置

默认情况下，es会开启gc日志。这个配置在jvm.option中可以修改，会将日志输出到和es日志的相同位置中。默认情况下每64mb会轮换一次，最多可以占用2GB的磁盘。

你可以使用JEP 158: Unified JVM Logging中的选项在命令行中配置jvm日志。除非你要修改默认的jvm.options文件，es将使用默认的配置应用在你没有设置的参数上。为了关闭默认的es配置，你首先要使用-Xlog:disable选项关闭日志，然后使用你自己在命令行配置的参数。这样所有的JVM日志都会关闭，所以你要确认选项是可以用的并且启动你需要的所有功能。

要查看原始JEP中未包含的更多选项，请参阅使用JVM统一日志框架启用日志记录。

例子

通过修改$ES_HOME/congif/jvm.option.d/gc.optins中的下面示例参数，将默认的GC日志输出路径修改为/opt/my-app/gc.log

# Turn off all previous logging configuratons
-Xlog:disable

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

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

修改ES的docker容器将GC的debug日志发送到标准错误中。这允许容器编排处理输出。如果使用ES_JAVA_OPTS环境变量，请指定

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

临时路径配置

默认情况下，ES使用的私有临时目录是使用脚本在系统的临时目录下创建的。

在部分linux的发型版中，系统的会清理/tem中长时间没有被访问的文件或文件夹。这个行为会导致当es正在运行中但是长时间没有访问过临时文件时临时文件会被删除。删除临时私有文件但如果随后使用了需要此目录的功能则会出现问题。

如果你使用的是.deb或.rpm包进行安装，并且运行在systemd下，那么es使用的临时私有目录将不再在定期的清理中被删除。

如果你想使用.tar.gz发行版是linux或MacOS并尝试使用的话，请考虑为ES创建一个专用临时目录，并且不在会被定时清理的目录下。这个目录应该设置额权限，以便只有Es用户可以用访问它。然后在ES启动之前设置$ES_TMPDIR环境变量并指向这个目录。

JVM fatal 错误日志谁在

默认情况，ES的默认配置会讲JVM的fatal级别的错误日志写入到默认的日志文件中。在RPM和Debin包中，这个目录是/var/log/elasticseach。在linux和MacOS还有window的发行版中，这个logs目录默认在ES的安装根目录下。

这个日志只有在JVM遇到致命的错误是才会生产，为了方便找到会单独打印。如果这个目录不适合用来存储此类日志，可以在jvm.opetin中输入-XX:ErrorFile=...对应参数进行修改。

集群备份

在集群故障时，快照可以有效的防范数据丢失，快照的生命周期管理是最简单有效用来备份集群的，更详细的信息后续会专门出文章进行分享。

警告:
	拍摄快照是唯一可靠且被支持的集群备份方法。你不能使用使用复制ES节点的数据目录来进行备份。ES不支持这样的方式将数据恢复到文件系统中。如果你尝试使用这样的方式恢复一个集群，那可能会导致集群报警出错，或者是丢失一些数据，也有可能导致数据的不一致，或者会出现集群显示成功，但是实际上却丢失了部分数据。