Elasticsearch之Linux环境安装介绍
1 Elasticsearch安装
1.1 版本介绍
在决定使用 Elasticsearch 的时候首先要考虑的是版本问题，Elasticsearch （排除 0.x 和 1.x）目前有如下常用的稳定的主版本：2.x，5.x，6.x，7.x（current）。
可能会发现没有 3.x 和 4.x，ES 从 2.4.6 直接跳到了 5.0.0。其实是为了 ELK（ElasticSearch，Logstash，Kibana）技术栈的版本统一，免的给用户带来混乱。
在 Elasticsearch 是 2.x （2.x 的最后一版 2.4.6 的发布时间是 July 25, 2017） 的情况下，Kibana 已经是 4.x（Kibana 4.6.5 的发布时间是 July 25, 2017）。那么在 Kibana 的下一主版本肯定是 5.x 了，所以 Elasticsearch 直接将自己的主版本发布为 5.0.0 了。
统一之后，我们选版本就不会犹豫困惑了，我们选定 Elasticsearch 的版本后再选择相同版本的 Kibana 就行了，不用担忧版本不兼容的问题。
Elasticsearch 是使用 Java 构建，所以除了注意 ELK 技术的版本统一，我们在选择 Elasticsearch 的版本的时候还需要注意 JDK 的版本。
因为每个大版本所依赖的 JDK 版本也不同，目前 7.2 版本已经可以支持 JDK11
1.2 单机
1.2.1 下载
官网下载：https://www.elastic.co/cn/downloads/elasticsearch#ga-release
下载linux版本有两个选择：
x86_64：就是我们常用的台式机的体系架构，是基于冯诺依曼体系架构的。x86_64 Linux可以理解为在普通台式机上安装的Linux操作系统。AArch64：是一种ARMv8架构，也是一种计算机的体系架构。AArch64 Linux可以理解为在ARMv8架构的计算机上安装的Linux操作系统。
使用Linux命令arch查看内核版本
[root@root ~]# arch
x86_64
如果用到了中文分词还需要下载ik分词器：https://github.com/medcl/elasticsearch-analysis-ik，如果不能访问github，就用国内的这个gitee也可以：https://gitee.com/mirrors/elasticsearch-analysis-ik/tree/master/
注意：IK分词器插件的版本要和ElasticSearch的版本一致
下载解压之后放到elasticsearch/pluging目录下面新建一个名字为ik的文件夹即可使用
1.2.2 安装配置
1.2.2.1 Elasticsearch
下载和解压 Elasticsearch，无需安装解压后即可用，解压后目录如上图：
bin：二进制系统指令目录，包含启动命令和安装插件命令等。config：配置文件目录。data：数据存储目录。lib：依赖包目录。logs：日志文件目录。modules：模块库，例如 x-pack 的模块。plugins：插件目录。
修改配置文件，在config下边的配置文件：elasticserach.yml
将里边的network,host放开 然后将ip修改为0.0.0.0，http.port放开
network.host: 0.0.0.0
http.port: 9200
安装目录下运行 bin/elasticsearch 来启动 ES。
默认在 9200 端口运行，请求 curl http://localhost:9200/ 或者浏览器输入 http://localhost:9200，得到一个 JSON 对象，其中包含当前节点、集群、版本等信息。
{
"name" : "U7fp3O9",
"cluster_name" : "elasticsearch",
"cluster_uuid" : "-Rj8jGQvRIelGd9ckicUOA",
"version" : {
"number" : "6.8.1",
"build_flavor" : "default",
"build_type" : "zip",
"build_hash" : "1fad4e1",
"build_date" : "2019-06-18T13:16:52.517138Z",
"build_snapshot" : false,
"lucene_version" : "7.7.0",
"minimum_wire_compatibility_version" : "5.6.0",
"minimum_index_compatibility_version" : "5.0.0"
},
"tagline" : "You Know, for Search"
}
1.2.2.2 IK分词器
IKAnalyzer.cfg.xml文件ES 目录/plugins/ik/config/IKAnalyzer.cfg.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE properties SYSTEM "http://java.sun.com/dtd/properties.dtd">
<properties>
<comment>IK Analyzer 扩展配置</comment>
<!--用户可以在这里配置自己的扩展字典 -->
<entry key="ext_dict"></entry>
<!--用户可以在这里配置自己的扩展停止词字典-->
<entry key="ext_stopwords"></entry>
<!--用户可以在这里配置远程扩展字典 -->
<!-- <entry key="remote_ext_dict">words_location</entry> -->
<!--用户可以在这里配置远程扩展停止词字典-->
<!-- <entry key="remote_ext_stopwords">words_location</entry> -->
</properties>
扩展字典中的词会被筛选出来，扩展停止词中的词会被过滤掉
1.2.3 报错
-
报错一：
can not run elasticsearch as root
es因为安全问题拒绝使用root用户启动
解决方法:- 添加用户组:
es，用户:es,she，设置密码 - 添加目录拥有权限
groupadd es
useradd es -g es -p password # -g 指定组 -p 密码
chown es:es -R elasticsearch-7.10.0/ # -R 处理指定目录以及其子目录下的所有文件 - 切换到es用户，启动
su es
./elasticsearch
./elasticsearch -d #后台方式启动
- 添加用户组:
-
报错二：
ignoring JAVA_HOME="XXXXX"； using bundled JDK JDK版本不对
elasticsearch支持JDK1.8的，仅仅是7.17.3及其之前的版本。如果下的最新版本，最低JDK得17及其以上。
win7建议下载7.6.1的版本，7.17.3需要win8和最低node.js 12.0.0版本 -
报错三：ik分词器，报错plugin-descriptor.properties
分析：由于是java开发的分词器，这里很明显是maven项目的目录结构。所以要执行打包命令，生成对应的发布的包
在ES中存放中文分词器的ik目录下执行mvn clean install命令，完成后在你target目录下的release中会有以下包，这些才是我们所需要的，用这些去替换ik中的文件。
-
报错四：对ik分词器项目打包时，提示类文件具有错误的版本 61.0, 应为 52.0
原因
SpringBoot使用了3.0或者3.0以上，因为Spring官方发布从Spring6以及SprinBoot3.0开始最低支持JDK17，所以仅需将SpringBoot版本降低为3.0以下即可
1.3 集群（Cluster）
ES的集群搭建很简单，不需要依赖第三方协调管理组件，自身内部就实现了集群的管理功能。
ES 集群由一个或多个 Elasticsearch 节点组成，每个节点配置相同的 cluster.name 即可加入集群，默认值为elasticsearch。
确保不同的环境中使用不同的集群名称，否则最终会导致节点加入错误的集群。
一个Elasticsearch服务启动实例就是一个节点（Node）。节点通过 node.name 来设置节点名称，如果不设置则在启动时给节点分配一个随机通用唯一标识符作为名称。
1.3.1 集群健康状态
要检查群集运行状况，我们可以在 Kibana 控制台中运行以下命令 GET /_cluster/health，得到如下信息：
{
"cluster_name" : "wujiajian",
"status" : "yellow",
"timed_out" : false,
"number_of_nodes" : 1,
"number_of_data_nodes" : 1,
"active_primary_shards" : 9,
"active_shards" : 9,
"relocating_shards" : 0,
"initializing_shards" : 0,
"unassigned_shards" : 5,
"delayed_unassigned_shards" : 0,
"number_of_pending_tasks" : 0,
"number_of_in_flight_fetch" : 0,
"task_max_waiting_in_queue_millis" : 0,
"active_shards_percent_as_number" : 64.28571428571429
}
集群状态通过 绿，黄，红 来标识：
绿色：集群健康完好，一切功能齐全正常，所有分片和副本都可以正常工作。黄色：预警状态，所有主分片功能正常，但至少有一个副本是不能正常工作的。此时集群是可以正常工作的，但是高可用性在某种程度上会受影响。红色：集群不可正常使用。某个或某些分片及其副本异常不可用，这时集群的查询操作还能执行，但是返回的结果会不准确。对于分配到这个分片的写入请求将会报错，最终会导致数据的丢失。
当集群状态为红色时，它将会继续从可用的分片提供搜索请求服务，但是你需要尽快修复那些未分配的分片
1.3.2 发现机制
那么有一个问题，ES 内部是如何通过一个相同的设置 cluster.name 就能将不同的节点连接到同一个集群的？答案是 Zen Discovery。
Zen Discovery 是 Elasticsearch 的内置默认发现模块（发现模块的职责是发现集群中的节点以及选举 Master 节点）。
它提供单播和基于文件的发现，并且可以扩展为通过插件支持云环境和其他形式的发现。
Zen Discovery 与其他模块集成，例如，节点之间的所有通信都使用 Transport 模块完成。节点使用发现机制通过 Ping 的方式查找其他节点。
Elasticsearch 默认被配置为使用单播发现，以防止节点无意中加入集群。只有在同一台机器上运行的节点才会自动组成集群。如果集群的节点运行在不同的机器上，使用单播，可以为 Elasticsearch 提供一些它应该去尝试连接的节点列表。
当一个节点联系到单播列表中的成员时，它就会得到整个集群所有节点的状态，然后它会联系 Master 节点，并加入集群。
这意味着单播列表不需要包含集群中的所有节点， 它只是需要足够的节点，当一个新节点联系上其中一个并且说上话就可以了。
如果使用 Master 候选节点作为单播列表，只要列出三个就可以了。这个配置在 elasticsearch.yml 文件中：
discovery.zen.ping.unicast.hosts: ["host1", "host2:port"]
节点启动后先 Ping ，如果 discovery.zen.ping.unicast.hosts 有设置，则 Ping 设置中的 Host ，否则尝试 ping localhost 的几个端口。
Elasticsearch 支持同一个主机启动多个节点，Ping 的 Response 会包含该节点的基本信息以及该节点认为的 Master 节点。
选举开始，先从各节点认为的 Master 中选，规则很简单，按照 ID 的字典序排序，取第一个。如果各节点都没有认为的 Master ，则从所有节点中选择，规则同上。这里有个限制条件就是 discovery.zen.minimum_master_nodes ，如果节点数达不到最小值的限制，则循环上述过程，直到节点数足够可以开始选举。
最后选举结果是肯定能选举出一个 Master ，如果只有一个 Local 节点那就选出的是自己。
如果当前节点是 Master ，则开始等待节点数达到 discovery.zen.minimum_master_nodes，然后提供服务。
如果当前节点不是 Master ，则尝试加入 Master 。Elasticsearch 将以上服务发现以及选主的流程叫做 Zen Discovery 。
由于它支持任意数目的集群（ 1- N ），所以不能像 Zookeeper 那样限制节点必须是奇数，也就无法用投票的机制来选主，而是通过一个规则。
只要所有的节点都遵循同样的规则，得到的信息都是对等的，选出来的主节点肯定是一致的。
但分布式系统的问题就出在信息不对等的情况，这时候很容易出现脑裂（Split-Brain）的问题。大多数解决方案就是设置一个 Quorum 值，要求可用节点必须大于 Quorum（一般是超过半数节点），才能对外提供服务。
而 Elasticsearch 中，这个 Quorum 的配置就是 discovery.zen.minimum_master_nodes
1.3.3 节点的角色
每个节点既可以是候选主节点也可以是数据节点，通过在配置文件 ../config/elasticsearch.yml 中设置即可，默认都为 true。
node.master: true //是否候选主节点
node.data: true //是否数据节点
数据节点负责数据的存储和相关的操作，例如对数据进行增、删、改、查和聚合等操作，所以数据节点（Data 节点）对机器配置要求比较高，对 CPU、内存和 I/O 的消耗很大。
通常随着集群的扩大，需要增加更多的数据节点来提高性能和可用性。
候选主节点可以被选举为主节点（Master 节点），集群中只有候选主节点才有选举权和被选举权，其他节点不参与选举的工作。
主节点负责创建索引、删除索引、跟踪哪些节点是群集的一部分，并决定哪些分片分配给相关的节点、追踪集群中节点的状态等，稳定的主节点对集群的健康是非常重要的。
一个节点既可以是候选主节点也可以是数据节点，但是由于数据节点对 CPU、内存核 I/O 消耗都很大。所以如果某个节点既是数据节点又是主节点，那么可能会对主节点产生影响从而对整个集群的状态产生影响。
因此为了提高集群的健康性，我们应该对 Elasticsearch 集群中的节点做好角色上的划分和隔离。可以使用几个配置较低的机器群作为候选主节点群。
主节点和其他节点之间通过 Ping 的方式互检查，主节点负责 Ping 所有其他节点，判断是否有节点已经挂掉。其他节点也通过 Ping 的方式判断主节点是否处于可用状态。
虽然对节点做了角色区分，但是用户的请求可以发往任何一个节点，并由该节点负责分发请求、收集结果等操作，而不需要主节点转发。
这种节点可称之为协调节点，协调节点是不需要指定和配置的，集群中的任何节点都可以充当协调节点的角色。
1.3.4 脑裂现象
1.3.3.1 发生原因
如果由于网络或其他原因导致集群中同时选举出多个 Master 节点，使得数据更新时出现不一致，这种现象称之为脑裂，即集群中不同的节点对于 Master 的选择出现了分歧，出现了多个 Master 竞争。
脑裂问题可能有以下几个原因造成：
网络问题： 集群间的网络延迟导致一些节点访问不到Master，认为Master挂掉了从而选举出新的Master，并对Master上的分片和副本标红，分配新的主分片。节点负载： 主节点的角色既为Master又为Data，访问量较大时可能会导致ES停止响应（假死状态）造成大面积延迟，此时其他节点得不到主节点的响应认为主节点挂掉了，会重新选取主节点。内存回收： 主节点的角色既为Master又为Data，当Data节点上的ES进程占用的内存较大，引发JVM的大规模内存回收，造成ES进程失去响应。
1.3.4.2 避免脑裂
为了避免脑裂现象的发生，我们可以从原因着手通过以下几个方面来做出优化措施：
- 适当调大响应时间，减少误判。 通过参数
discovery.zen.ping_timeout设置节点状态的响应时间，默认为3s，可以适当调大。
如果Master在该响应时间的范围内没有做出响应应答，判断该节点已经挂掉了。调大参数（如 6s，discovery.zen.ping_timeout:6），可适当减少误判。 - 选举触发。 我们需要在候选集群中的节点的配置文件中设置参数
discovery.zen.minimum_master_nodes的值。这个参数表示在选举主节点时需要参与选举的候选主节点的节点数，默认值是1，官方建议取值master候选节点数量/2+1
这样做既能防止脑裂现象的发生，也能最大限度地提升集群的高可用性，因为只要不少于discovery.zen.minimum_master_nodes个候选节点存活，选举工作就能正常进行。当小于这个值的时候，无法触发选举行为，集群无法使用，不会造成分片混乱的情况。 - 角色分离。 即是上面我们提到的候选主节点和数据节点进行角色分离，这样可以减轻主节点的负担，防止主节点的假死状态发生，减少对主节点“已死”的误判。
