elasticsearch集群内原理

集群内原理

本章讲解如何按需配置集群、节点和分片，并在硬件故障时确保数据安全

空集群

master节点负责管理集群范围内的所有变更，例如增加、删除索引，或者增加、删除节点等，但不需要涉及到文档级别的变更和搜索等操作

集群中的任何节点都知道任意文档所处的位置,并且能够直接转发请求到存储我们所需文档的节点拿数据

集群健康

查询

GET /_cluster/health

结果

{
"cluster_name": "elasticsearch",
"status": "yellow",
"timed_out": false,
"number_of_nodes": 1,
"number_of_data_nodes": 1,
"active_primary_shards": 6,
"active_shards": 6,
"relocating_shards": 0,
"initializing_shards": 0,
"unassigned_shards": 6,
"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": 50
}

status含义

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

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

有主分片没能正常运行

添加索引

索引: 索引实际上是指向一个或者多个物理 分片 的 逻辑命名空间，应用程序直接与索引而不是与分片进行交互

分片: 一个 分片 是一个底层的 工作单元，数据的容器（也是一个 Lucene 的实例，本身是一个搜索引擎），文档保存在分片内，分片又被分配到集群内的各个节点里(随着集群规模，elasticsearch自动迁移分片，使得数据均匀分布在集群)

主分片：索引建立时就已经确定数目(默认5)，任意一个文档都归属于一个主分片(按理一个主分片最大能够存储128个文档)，主分片的数目决定着索引能够保存的最大数据量

副分片：主分片的拷贝，数目可以随时修改，作为硬件故障时保护数据不丢失的冗余备份，并为搜索和返回文档等读操作提供服务

创建索引并设置主副分片数

PUT /blogs
{
"settings" : {
"number_of_shards" : 3,
"number_of_replicas" : 1
}
}

返回结果中包含： “unassigned_shards”: 3, 没有被分配到任何节点的副本数，主副分片只在一个节点，如节点挂掉，存在数据丢失风险

添加故障转移

如集群中只有一个节点在运行，意味着会有单个节点故障问题，没有冗余，只需再启动一个节点即可

同一台机器，可以共享同一个目录，完全按照第一个节点方式启动第二个新节点，只要有相同的claster.name就会自动发现集群

不同机器，需要配置一个可连接到的单播主机列表，以防止使用组播时节点无意中加入集群，组播使得集群变得脆弱， 当一个节点联系到单播列表中的成员时，它就会得到整个集群所有节点的状态，然后它会联系 master 节点，并加入集群

单播列表不需要包含你的集群中的所有节点， 它只是需要足够的节点，
当一个新节点联系上其中一个并且说上话就可以了。
如果你使用 master 候选节点作为单播列表，你只要列出三个就可以了
elasticsearch.yml中加入:
discovery.zen.ping.unicast.hosts: ["host1", "host2:port"]

水平扩容

扩容能够让更少的分片分配到每个节点，每个分片性能也得到提升，但如果3个分片，3个副分片，扩容到6个节点，每个节点一个分片的情况下，还想继续扩容，则可以修改每个副分片的数量,能够提高集群搜索性能

PUT /blogs/_settings
{
"number_of_replicas" : 2
}

如果在相同节点数目的集群上增加更多的副本分片并不能提高性能，提高数据冗余量，但是丢失节点不一定会丢失数据

应对故障

当一个节点缺失，并且某主分片，也在丢失节点中，则只要其他节点存在该分片的副本，则副分片会瞬间选举成主分片