ES集群部署

每个节点上运行/elasticsearch-568/bin/elasticsearch -d （参数-d表示后台运行）

/kibana-568/bin/kinana (若后台运行，使用nohup /kibana-568/bin/kinana &)

之前的ES集群版本为568，且未使用xpack组件进行权限管理，新集群版本为781，使用xpack增加Auth（需密码登录）和SSL （节点间通信加密），具体步骤如下：

ES现在是很多系统中不可或缺的一部分，为了在使用时快速的部署一个ES环境，这里记录一下自己的一些 *** 作步骤。
所有的 *** 作都是基于Docker来的，没有装Docker的话请参照 官方文档 安装
采用的ES版本为6813
宿主机系统为Centos 78
单机版添加密码验证
集群版使用ssl传输

将下面的内容粘贴到elasticsearchyml

ES_JAVA_OPTS设置了ES的启动内存，自己按需修改
discoverytype=single-node表示该es为单节点，不加这个的话，你的es健康状态会显示为

根据提示，先输入y，然后输入密码，这里会要求输入多次，主要是需要给好几个系统添加密码，用户默认elastic

至此，单节点的elasticsearch就部署好了，通过elasticsearch head即可连接使用

生成的ssl证书在用户目录certs下 cd ~/certs 即可看到
后续步骤需要在每一台集群服务器上执行

NODE_LIST：配置集群中其他节点的地址，格式为：ip:port,ip2:port2
NODE_NAME：当前节点的name

至此，搭建就完了

我们一般在开发与测试的使用使用的单节点的es，节约资源嘛，而在生产的时候，那肯定就需要上集群了，这时候在开发与测试环境的时候，java的连接配置就会与生产有一些出入
我一般都是用的 spring-boot-starter-data-elasticsearch 搭配 x-pack-transport 来连接
先引入相关的依赖

版本号这东西自己注意下哈，es对这还是挺敏感的

这里主要是通过isCluster这个配置来区分的
如果连接的是集群，由于我们之前为集群配置了一个ssl证书，所以java连接的时候也是需要使用那个证书的，所以会多出来几个配置

垂直扩容：使用更加强大的服务器替代老服务器。但单机存储及运算能力有上线。且成本直线上升。如10t服务器1万。单个10T服务器可能20万。

水平扩容：采购更多服务器，加入集群。大数据。

新增或减少es实例时，es集群会将数据重新分配。

功能：

注意：es7以前primary shard的默认数量是5，replica默认是1，默认有10个shard，5个primary shard，5个replica shard

以3分片，2副本数，3节点为例。

主结点：master节点主要用于集群的管理及索引 比如新增结点、分片分配、索引的新增和删除等。 数据结点：data 节点上保存了数据分片，它负责索引和搜索 *** 作。 客户端结点：client 节点仅作为请求客户端存在，client的作用也作为负载均衡器，client 节点不存数据，只是将请求均衡转发到其它结点。

通过下边两项参数来配置结点的功能：

四种组合方式：

es提供了一套api，叫做cat api，可以查看es中各种各样的数据

GET /_cat/healthv

如何快速了解集群的健康状况？green、yellow、red？

green：每个索引的primary shard和replica shard都是active状态的

yellow：每个索引的primary shard都是active状态的，但是部分replica shard不是active状态，处于不可用的状态

red：不是所有索引的primary shard都是active状态的，部分索引有数据丢失了

GET /_cat/indicesv

官方建议： Min（32GB，机器内存大小/2）。
磁盘需求最优比例=1:50 256g=12800G=13T
8G内存对应850=400G磁盘
总体内存大小没有具体要求，但肯定是内容越大，检索性能越好。
除了JVM之外的预留内存要充足，否则也会经常OOM。

集群节点数：<=3，建议：所有节点的master：true， data：true。既是主节点也是路由节点。
集群节点数：>3, 根据业务场景需要，建议：逐步独立出Master节点和协调/路由节点。

ES 集群中的数据节点负责对数据进行增、删、改、查和聚合等 *** 作，所以对 CPU、内存和 I/O 的消耗很大。
在搭建 ES 集群时，我们应该对 ES 集群中的节点进行角色划分和隔离。
候选主节点：nodemaster= true node data= false
数据节点：nodemaster= false node data= true

网络异常可能会导致集群中节点划分出多个区域，区域发现没有 Master 节点的时候，会选举出了自己区域内 Maste 节点 r，导致一个集群被分裂为多个集群，使集群之间的数据无法同步，我们称这种现象为脑裂。
为了防止脑裂，我们需要在 Master 节点的配置文件中添加如下参数：
discoveryzenminimum_master_nodes=（master_eligible_nodes /2）+1 //默认值为 1
其中 master_eligible_nodes 为 Master 集群中的节点数。这样做可以避免脑裂的现象都出现，最大限度地提升集群的高可用性。
只要不少于 discoveryzenminimum_master_nodes 个候选节点存活，选举工作就可以顺利进行，即保持至少一半节点存活。

建议根据数据量衡量。经验值：建议每个分片大小不要超过30GB。

单个索引分片数=数据量÷30g
每个节点建议的单个索引分片数＜3：因为分片分布在同一个服务器上。请求开始竞争相同的硬件资源时, 性能便会逐步下降。
如果该索引分片数过多可以考虑业务需求是否需要分割索引。周表，天表，月表等划分。

注意：除非reindex *** 作，分片数是不可以修改的。

在Elasticsearch中，每个查询在每个分片的单个线程中执行。然而，可以并行处理多个分片，并可以在相同分片上执行多个查询和聚合。
小分片的利弊这意味着，在不涉及高速缓存时，最小查询延迟将取决于数据、查询的类型、分片的大小。查询大量小分片将使得每个分片的处理速度更快，但是随着更多的任务需要按顺序排队和处理，它不一定要比查询较小数量的更大的分片更快。如果有多个并发查询，则有很多小碎片也会降低查询吞吐量。

除非你对系统的健壮性有异常高的要求，比如：银行系统。可以考虑2个副本以上。否则，1个副本足够。
注意：副本数是可以通过配置随时修改的。

根据业务需要选择合适的类型，有利于节省空间和提升精度。Fetch方法只返回要查询的字段，对每组数据做校验，可以避免使用默认mapping的字段类型，增加写入速度、节省空间。

尽量避免使用nested或 parent/child，能不用就不用；nested query慢， parent/child query 更慢，比nested query慢上百倍；因此能在mapping设计阶段搞定的（大宽表设计或采用比较smart的数据结构），就不要用父子关系的mapping。如果一定要使用nested fields，保证nested fields字段不能过多，目前ES默认限制是50。
indexmappingnested_fieldslimit ：50

ES 配置说明
配置文件：elasticsearchyaml。
ES 的配置信息有很多种，大部分配置都可以通过 elasticsearchyaml 和接口的方式进行。
下面我们列出一些比较重要的配置信息：

单节点安装

ES安装包文件夹说明

集群安装

es集群配置

安装博客地址

kibana配置 kibana的更详细的配置解释可以参考
>

分片：分片就是对数据切分成了多个部分，Elasticsearch 默认会把一个索引分成五个分片，

数据保存在分片内，分片又被分配到集群内的各个节点里

副本：副本就是对原分片的复制，和原分片的内容是一样的，Elasticsearch 默认会生成一份副本，所以相当于是五个原分片和五个分片副本，相当于一份数据存了两份，并分了十个分片

主节点：即 Master 节点。主节点的主要职责是和集群 *** 作相关的内容，如创建或删除索引，跟踪哪些节点是群集的一部分，并决定哪些分片分配给相关的节点。稳定的主节点对集群的 健康 是非常重要的。默认情况下任何一个集群中的节点都有可能被选为主节点。索引数据和搜索查询等 *** 作会占用大量的cpu，内存，io资源，为了确保一个集群的稳定，分离主节点和数据节点是一个比较好的选择。虽然主节点也可以协调节点，路由搜索和从客户端新增数据到数据节点，但最好不要使用这些专用的主节点。一个重要的原则是，尽可能做尽量少的工作。

数据节点：即 Data 节点。数据节点主要是存储索引数据的节点，主要对文档进行增删改查 *** 作，聚合 *** 作等。数据节点对 CPU、内存、IO 要求较高，在优化的时候需要监控数据节点的状态，当资源不够的时候，需要在集群中添加新的节点。

负载均衡节点：也称作 Client 节点，也称作客户端节点。当一个节点既不配置为主节点，也不配置为数据节点时，该节点只能处理路由请求，处理搜索，分发索引 *** 作等，从本质上来说该客户节点表现为智能负载平衡器。独立的客户端节点在一个比较大的集群中是非常有用的，他协调主节点和数据节点，客户端节点加入集群可以得到集群的状态，根据集群的状态可以直接路由请求。

预处理节点：也称作 Ingest 节点，在索引数据之前可以先对数据做预处理 *** 作，所有节点其实默认都是支持 Ingest *** 作的，也可以专门将某个节点配置为 Ingest 节点。

1Master：主节点，每个集群都有且只有一个

尽量避免Master节点又是数据节点： nodedata true

主节点的主要职责是负责集群层面的相关 *** 作，管理集群变更，如创建或删除索引，跟踪哪些节点是群集的一部分，并决定哪些分片分配给相关的节点。

2Voting：投票节点

nodevoting_only = true（仅投票节点，即使配置了datamaster = true，也不会参选, 但是仍然可以作为数据节点）。

3Coordinating：协调节点

每一个节点都隐式的是一个协调节点，如果同时设置了datamaster = false和datadata=false，那么此节点将成为仅协调节点。

4Master-eligible node（候选节点）

可以通过选举成为Master的节点

5Data node（数据节点）

主要负责数据存储和查询服务

配置：

这是ES节点默认配置，既作为候选节点又作为数据节点，这样的节点一旦被选举为Master，压力是比较大的，通常来说Master节点应该只承担较为轻量级的任务，比如创建删除索引，分片均衡等。

只作为候选节点，不作为数据节点，可参选Master节点，当选后成为真正的Master节点。

既不当候选节点，也不作为数据节点，那就是仅协调节点，负责负载均衡

不作为候选节点，但是作为数据节点，这样的节点主要负责数据存储和查询服务。

协调节点是如何工作的，他是怎么找到对应的节点的

每个节点都保存了集群的状态,只有Master节点才能修改集群的状态信息
集群状态(Cluster Starte),维护了一个集群中,必要的信息
所有的节点信息
所有的索引和其相关的Mapping与Setting信息
分片的路由信息

协调节点作为es节点中的一个节点，默认情况下es集群中所有的节点都能当协调节点，主要作用于请求转发，请求响应处理等轻量级 *** 作。

这意味着如果它们接收到用户请求，它们就可以处理用户请求

status 字段指示着当前集群在总体上是否工作正常。它的三种颜色含义如下：

green 所有的主分片和副本分片都正常运行。

yellow 所有的主分片都正常运行，但不是所有的副本分片都正常运行。

red 有主分片没能正常运行

当索引一个文档的时候，文档会被存储到一个主分片中。 Elasticsearch 如何知道一个文档应该存放到哪个分片中呢？当我们创建文档时，它如何决定这个文档应当被存储在分片 1 还是分片 2 中呢？

首先这肯定不会是随机的，否则将来要获取文档的时候我们就不知道从何处寻找了。实际上，这个过程是根据下面这个公式决定的：

routing 是一个可变值，默认是文档的 _id ，也可以设置成一个自定义的值。 routing 通过 hash 函数生成一个数字，然后这个数字再除以 number_of_primary_shards （主分片的数量）后得到 余数 。这个分布在 0 到 number_of_primary_shards-1 之间的余数，就是我们所寻求的文档所在分片的位置。

我们可以发送请求到集群中的任一节点。 每个节点都有能力处理任意请求。 每个节点都知道集群中任一文档位置，所以可以直接将请求转发到需要的节点上。 在下面的例子中，将所有的请求发送到 Node 1 ，我们将其称为 协调节点(coordinating node) 。

以下是在主副分片和任何副本分片上面 成功新建，索引和删除文档所需要的步骤顺序：

consistency 一直性： 参数的值可以设为 one （只要主分片状态 ok 就允许执行_写_ *** 作）, all （必须要主分片和所有副本分片的状态没问题才允许执行_写_ *** 作）, 或 quorum 。默认值为 quorum , 即大多数的分片副本状态没问题就允许执行_写_ *** 作。

master选举当然是由master-eligible节点发起

深入理解 Elasticsearch 7x 新的集群协调层：

>