文章概要：
- 1. 节点分类和职责
- 2. 部署集群环境
- 3. 单节点集群
- 4. 添加故障转移
- 5. 水平扩容
- 6. 应对故障
本系列往期文章：
初识ElasticSearch - 01 认识搜索引擎
初识ElasticSearch - 02 ElasticSearch的基本概念
当一个节点被选举成为主节点时， 它将负责管理集群范围内的所有变更，例如增加、删除索引，或者增加、删除节点等。 而主节点并不需要涉及到文档级别的变更和搜索等操作，所以当集群只拥有一个主节点的情况下，即使流量的增加它也不会成为瓶颈。 任何节点都可以成为主节点。
作为用户，我们可以将请求发送到集群中的任何节点 ，包括主节点。 每个节点都知道任意文档所处的位置，并且能够将我们的请求直接转发到存储我们所需文档的节点。 无论我们将请求发送到哪个节点，它都能负责从各个包含我们所需文档的节点收集回数据，并将最终结果返回給客户端。 Elasticsearch对这一切的管理都是透明的。
从集群节点角色的角度划分，至少存在主节点和数据节点，另外还有协调节点、预处理节点和部落节点：
1.1 主节点
主节点负责管理整个集群。它管理所有节点的状态，并周期性地将集群状态同步到集群中的所有其他节点，通知大家有什么新节点加入了集群，有什么节点脱离了集群。主节点会定期向所有其他节点发送ping消息，以此判断它们是否正常存活（别的节点也会向主节点发送ping消息）。主节点的重要任务之一是配置管理。它管理着全部元数据，以及集群中所有索引的映射。如果主节点下线了，就会从所有候选主节点中再选出一个新的主节点来。默认情况下，每个节点都可以成为主节点。可以在elasticsearch.yml文件中通过配置node.master: true（默认）来使一个节点成为数据节点。
node.master: true node.data: false
1.2 数据节点
Elasticsearch中的数据节点负责保存数据、段合并和执行查询。数据节点是集群中真正承担工作任务的地方，对CPU、内存、I/O要求较高，因此服务器的配置应该比集群中的其他节点高。默认情况下，每个节点都可以成为数据节点。可以在elasticsearch.yml文件中通过配置node.data: true（默认）来使一个节点成为数据节点，指定数据节点的好处是可以做到主节点与数据节点之间的分离。
node.master: false node.data: true node.ingest: false
1.3 预处理节点
预处理操作允许在索引文档之前，即写入数据之前，通过事先定义好的一系列的processors（处理器）和pipeline（管道），对数据进行某种转换、富化。processors和pipeline拦截bulk和index请求，在应用相关操作后将文档传回给index或bulk API·。默认情况下，在所有的节点上启用ingest，如果想在某个节点上禁用ingest，则可以添加配置node.ingest: false。
node.master: false node.data: true node.ingest: false
1.4 协调节点
客户端请求可以发送到集群的任何节点，每个节点都知道任意文档所处的位置，然后转发这些请求，收集数据并返回给客户端，处理客户端请求的节点称为协调节点。在Elasticsearch中，查询的执行过程可以分为两个阶段：分散阶段和集中阶段。两个阶段都由接收查询请求的协调节点来管理。它们也是集群中的负载均衡器。在分散阶段，协调节点将查询请求转发给保存数据的数据节点。每个数据节点都在本地执行查询，再将结果返回给协调节点。在集中阶段，协调节点将所有数据节点返回的结果合并成一个总结果集，对结果收集和排序的过程可能需要很多CPU和内存资源。每个节点默认都是协调节点。在大型集群中，指定协调节点是个好习惯，这样可以将负载从数据节点和主节点分离出来。可以通过在文件elasticsearch.yml中通过下面的配置创建一个仅用于协调的节点：
node.master: false node.data: false node.ingest: false
1.5 部落节点
部落节点是一种特殊类型的协调节点，它可以连接多个集群，并在连上的所有集群中执行查询或其他操作。
2. 部署集群环境2.1 修改集群配置文件
创建 elasticsearch-cluster 文件夹，在内部复制三个elasticsearch 服务，修改集群文件目录中每个节点的 config/elasticsearch.yml 配置文件：
① node-1001节点：
# 节点 1 的配置信息： # 集群名称，节点之间要保持一致 cluster.name: my-elasticsearch # 节点名称，集群内要唯一 node.name: node-1001 node.master: true node.data: true # 存放数据的目录地址 path.data: F:installelasticsearch-7.4.2-windows-x86_64elasticsearch-clusternode-1001data # 存放日志的目录地址 path.logs: F:installelasticsearch-7.4.2-windows-x86_64elasticsearch-clusternode-1001logs # ip 地址 network.host: localhost # http 端口 http.port: 1001 # tcp 监听端口 transport.tcp.port: 9301 #discovery.seed_hosts: ["localhost:9301", "localhost:9302","localhost:9303"] #discovery.zen.fd.ping_timeout: 1m #discovery.zen.fd.ping_retries: 5 # 跨域配置 http.cors.enabled: true http.cors.allow-origin: "*"
②node-1002节点：
# 节点 2 的配置信息： # 集群名称，节点之间要保持一致 cluster.name: my-elasticsearch # 节点名称，集群内要唯一 node.name: node-1002 node.master: true node.data: true # 存放数据的目录地址 path.data: F:installelasticsearch-7.4.2-windows-x86_64elasticsearch-clusternode-1002data # 存放日志的目录地址 path.logs: F:installelasticsearch-7.4.2-windows-x86_64elasticsearch-clusternode-1002logs # ip 地址 network.host: localhost # http 端口 http.port: 1002 # tcp 监听端口 transport.tcp.port: 9302 discovery.seed_hosts: ["localhost:9301"] discovery.zen.fd.ping_timeout: 1m discovery.zen.fd.ping_retries: 5 # 集群内的可以被选为主节点的节点列表 # cluster.initial_master_nodes: ["node-1", "node-2","node-3"] # 跨域配置 # action.destructive_requires_name: true http.cors.enabled: true http.cors.allow-origin: "*"
③ node-1003节点
# 节点 3 的配置信息： # 集群名称，节点之间要保持一致 cluster.name: my-elasticsearch # 节点名称，集群内要唯一 node.name: node-1003 node.master: true node.data: true # 存放数据的目录地址 path.data: F:installelasticsearch-7.4.2-windows-x86_64elasticsearch-clusternode-1003data # 存放日志的目录地址 path.logs: F:installelasticsearch-7.4.2-windows-x86_64elasticsearch-clusternode-1003logs # ip 地址 network.host: localhost # http 端口 http.port: 1003 # tcp 监听端口 transport.tcp.port: 9303 # 候选主节点的地址，在开启服务后可以被选为主节点 discovery.seed_hosts: ["localhost:9301", "localhost:9302"] discovery.zen.fd.ping_timeout: 1m discovery.zen.fd.ping_retries: 5 # 集群内的可以被选为主节点的节点列表 #cluster.initial_master_nodes: ["node-1", "node-2","node-3"] # 跨域配置 #action.destructive_requires_name: true http.cors.enabled: true http.cors.allow-origin: "*"
2.2 启动集群
① 启动前先删除每个节点中的 data 目录中所有内容（如果存在）
② 分别双击执行 bin/elasticsearch.bat, 启动节点服务器，启动后，会自动加入指定名称的集群
2.3 查看集群状态
①node-1001节点
② node-1002节点
③ node-1003节点
status 字段指示着当前集群在总体上是否工作正常。它的三种颜色含义如下：
- green：所有的主分片和副本分片都正常运行。
- yellow：所有的主分片都正常运行，但不是所有的副本分片都正常运行。
- red：有主分片没能正常运行。
2.4 测试集群
① 向集群node-1001中插入索引：
② 在集群node-1002中查看索引
再来理解这句话：
一个运行中的 Elasticsearch实例称为一个节点，而集群是由一个或者多个拥有相同cluster.name 配置的节点组成， 它们共同承担数据和负载的压力。当有节点加入集群中或者从集群中移除节点时，集群将会重新平均分布所有的数据。
作为用户，我们可以将请求发送到集群中的任何节点 ，包括主节点。 每个节点都知道任意文档所处的位置，并且能够将我们的请求直接转发到存储我们所需文档的节点。 无论我们将请求发送到哪个节点，它都能负责从各个包含我们所需文档的节点收集回数据，并将最终结果返回給客户端。
3. 单节点集群如果我们启动了一个单独的节点node-1001，里面不包含任何的数据和索引，那我们的集群看起来就是一个包含空内容节点的集群 ，在包含一个空节点的集群内创建名为users的索引，为了演示目的，分配 3个主分片和一份副本（每个主分片拥有一个副本分片）
{
"settings" : {
"number_of_shards" : 3,
"number_of_replicas" : 1
}
}
我们的集群现在是拥有一个索引的单节点集群，3个主分片都被分配在 node-1001
通过elasticsearch-head插件查看集群情况 :
集群的健康状况为 yellow 则表示全部主分片都正常运行（集群可以正常服务所有请求），但是副本分片没有全部处在正常状态。 实际上，所有3个副本分片都是 unassigned—— 它们都没有被分配到任何节点。 在同一个节点上既保存原始数据又保存副本是没有意义的，因为一旦失去了那个节点，我们也将丢失该节点上的所有副本数据。当前我们的集群是正常运行的，但是在硬件故障时有丢失数据的风险。
当集群中只有一个节点在运行时，意味着会有一个单点故障问题——没有冗余。 幸运的是，我们只需再启动一个节点即可防止数据丢失。当你在同一台机器上启动了第二个节点时，只要它和第一个节点有同样的cluster.name配置，它就会自动发现集群并加入到其中。
但是在不同机器上启动节点的时候，为了加入到同一集群，你需要配置一个可连接到的单播主机列表。之所以配置为使用单播发现，以防止节点无意中加入集群。只有在同一台机器上运行的节点才会自动组成集群。
如果启动了第二个节点，我们的集群将是拥有两个节点的集群 : 所有主分片和副本分片都已被分配 。
通过 elasticsearch-head 插件查看集群情况 :
当第二个节点加入到集群后，3个副本分片将会分配到这个节点上——每个主分片对应一个副本分片。 这意味着当集群内任何一个节点出现问题时，我们的数据都完好无损。
所有新近被索引的文档都将会保存在主分片上，然后被并行的复制到对应的副本分片上。这就保证了我们既可以从主分片又可以从副本分片上获得文档。
5. 水平扩容吞吐量：单位时间内成功地传送数据的数量
怎样为正在增长中的应用程序按需扩容呢？当启动了第3个节点，我们的集群将是拥有3个节点的集群 ，当集群节点增加的时候，会对分片进行重新分配，让每个节点上都均匀的分配相同数量的分片，即每个节点上分配2个分片，且主分片和副本分片是不能在同一个节点上。
拥有三个节点的集群——为了分散负载而对分片进行重新分配
通过elasticsearch-head 插件查看集群情况 :
node-1001 和 node-1002 上各有一个分片被迁移到了新的 node-1003 节点，现在每个节点上都拥有2个分片，而不是之前的3个。 这表示每个节点的硬件资源（CPU, RAM, I/O）将被更少的分片所共享，每个分片的性能将会得到提升。
分片是一个功能完整的搜索引擎，它拥有使用一个节点上的所有资源的能力。 我们这个拥有6个分片（3个主分片和3个副本分片）的索引可以最大扩容到6个节点，每个节点上存在一个分片，并且每个分片拥有所在节点的全部资源。（因为6个分片，因此最大扩容到6个节点，如果7个节点，那就没法分配了）。
但是如果我们想要扩容超过 6 个节点怎么办呢？
主分片的数目在索引创建时就已经确定了下来。实际上，这个数目定义了这个索引能够 存储 的最大数据量。（实际大小取决于你的数据、硬件和使用场景。） 但是，读操作——搜索和返回数据——可以同时被主分片或副本分片所处理，所以当你拥有越多的副本分片时，也将拥有越高的吞吐量。
在运行中的集群上是可以动态调整副本分片数目的，可以按需伸缩集群。我们把副本数从默认的 1 增加到 2 :
users 索引现在拥有 9 个分片： 3个主分片和 6 个副本分片。 这意味着我们可以将集群扩容到 9 个节点，每个节点上一个分片。相比原来 3 个节点时，集群搜索性能可以提升 3 倍 。
通过 elasticsearch-head插件查看集群情况 ：
当然，如果只是在相同节点数目的集群上增加更多的副本分片并不能提高性能，因为每个分片从节点上获得的资源会变少。 你需要增加更多的硬件资源来提升吞吐量。但是更多的副本分片数提高了数据冗余量：按照上面的节点配置，我们可以在失去2个节点的情况下不丢失任何数据。
Elasticsearch 可以应对节点故障，接下来让我们尝试下这个功能。 如果我们关闭第一个节点，这时集群的状态为：关闭了一个节点后的集群。
我们关闭的节点是一个主节点。而集群必须拥有一个主节点来保证正常工作，所以发生的第一件事情就是选举一个新的主节点： node-1002 。通过 elasticsearch-head插件查看集群情况 ：
在我们关闭 node-1001 的同时也失去了主分片 1 和 2 ，并且在缺失主分片的时候索引也不能正常工作。 如果此时来检查集群的状况，我们看到的状态将会为 red ：不是所有主分片都在正常工作。
幸运的是，在其它节点上存在着这两个主分片的完整副本， 所以新的主节点立即将这些分片在 node-1002 和 node-1003 上对应的副本分片提升为主分片， 此时集群的状态将会为 yellow 。 这个提升主分片的过程是瞬间发生的，如同按下一个开关一般。
为什么我们集群状态是 yellow 而不是 green 呢？ 虽然我们拥有所有的三个主分片，但是同时设置了每个主分片需要对应2份副本分片，而此时只存在一份副本分片。 所以集群不能为 green 的状态，不过我们不必过于担心：如果我们同样关闭了 node-1002 ，我们的程序 依然 可以保持在不丢任何数据的情况下运行，因为 node-1003 为每一个分片都保留着一份副本。
如果我们重新启动 node-1001，集群可以将缺失的副本分片再次进行分配，那么集群的状态也将恢复成之前的状态。 如果node-1001依然拥有着之前的分片，它将尝试去重用它们，同时仅从主分片复制发生了修改的数据文件。和之前的集群相比，只是 Master 节点切换了。
重启之前，在node-1001节点的配置文件elasticsearch.yml中添加：
discovery.seed_hosts: ["localhost:9302", "localhost:9303"]
通过 elasticsearch-head插件查看集群情况 ：
