elasticseach8.x-集群

什么是ES集群

当加入新的节点或者删除一个节点时,集群就会感知到并平衡数据(同步)

什么是集群节点

1、ES集群有多个节点,会自动选取一个节点为master节点

2、master节点就是干一些管理的工作,比如维护索引元数据,负责切换primary shard 和replic shard 身份等,要是master 节点宕机,那么会重新选举master。

3、如果是非master 节点宕机了,那么master 节点,让那个宕机节点上的primary shard 的身份转移到其他机器上的replic shard,接着要是修复了那个宕机机器,重启之后,master 节点会控制将缺失的relica shard 分配过去,同步后续修改的数据之类的,让集群回复正常
3、主节点不参与文档级别的变更或搜索
4、任何节点都可以成为主节点。
5、用户,我们能够与集群中的任何节点通信,包括主节点。
6、每一个节点都知道文档存在于哪个节点上,它们可以转发请求到相应的节点上。
7、我们访问的节点负责收集各节点返回的数据,最后一起返回给客户端。这一切都由Elasticsearch处理

什么是集群分片

索引就是我们理解就是mysql数据库

索引只是一个用来指向一个或多个分片(shards)的“逻辑命名空间(logical namespace)”.

分片(shard)是一个最小级别工作单元(worker unit),它只是保存了索引中所有数据的一部分。

创建一个索引index,这个索引可以被拆分成多个shard,每个shard存储部分数据量,拆分多个shard的好处是:一是支持横向扩展,比如,你有3T的数据量,3个shard,每个shard也就1T的数据,若现在数据增加到4T,怎么扩展?很简单,重新创建索引,拆分成4个shard,将数据导进去(mapping和data),二是提高性能,数据分布在多个shard上,即多台服务器上,所有操作都会在多台服务器上并行分布式执行,提高吞吐量和性能。

主分片

索引中的每个文档属于一个单独的主分片,所以主分片的数量决定了索引最多能存储多少数据。理论上主分片能存储的数据大小是没有限制的,限制取决于你实际的使用情况。分片的最大容量完全取决于你的使用状况:硬件存储的大小、文档的大小和复杂度、如何索引和查询你的文档,以及你期望的响应时间。

分片数由index.number_of_shards在索引创建的时候指定,如果需要修改主分片数,需要重建索引:
1 按照需要创建一个新的索引;
2 reindex把索引现有的数据同步到新索引中;
3 别名绑定新创建的索引上;

规避主分片不能修改的问题的方法,官方的说明:

我们当前的选择只有一个就是将数据重新索引至一个拥有更多分片的一个更大的索引,但这样做将消耗的时间是我们无法提供的。

副本分片

复制分片只是主分片的一个副本,它可以防止硬件故障导致的数据丢失,同时可以提供读请求,比如搜索或者从别的shard取回文档。

当索引创建完成的时候,主分片的数量就固定了,但是复制分片的数量可以随时调整。

副本分片保存的是其他集群节点的主分片数据

在同一个节点上保存相同的数据副本是没有必要的,如果这个节点故障了,那所有副本也会丢失。但如果保存在其他节点,即使这个节点挂了,还可以从其他节点找回副本。

1.创建索引

put:https://localhost:9200/customer

{
   "settings" : {
      "number_of_shards" : 3, #3个主分片
      "number_of_replicas" : 1 #每个主分片一个副本分片
   }
}

2.增加副本分片

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

 

集群路由

文档路由

document路由到shard分片上,就叫做文档路由 ,如何路由?

路由算法

算法公式:shard = hash(routing)%number_of_primary_shards

例子:

一个索引index ,有3个primary shard : p0,p1,p2

增删改查 一个document文档时候,都会传递一个参数 routing number, 默认就是document文档 _id, (也可以手动指定)

Routing = _id,假设: _id = 1

算法:

Hash(1) = 21 % 3 = 0 表示 请求被 路由到 p0分片上面。

自定义路由请求:
PUT /index/item/id?routing = _id (默认)

PUT /index/item/id?routing = user_id(自定义路由)--- 指定把某些值固定路由到某个分片上面。

primary shard不可变原因

 

集群常用监控

head插件

https://www.cnblogs.com/LQBlog/p/18575068

查看集群健康

https://localhost:9200/_cat/health?v

epoch      timestamp cluster        status n  ode.total node.data shards pri relo init unassign pending_tasks max_task_wait_time active_shards_percent
1668239928 07:58:48  docker-cluster green           3         3     22   11    0    0        0             0                  -                100.0%

或者https://localhost:9200/_cluster/health

入参(可选):

evel    指定查询的层级,可选cluster, indices 和 shards ,默认cluster
local    是否从本地node查询,默认false从master节点查询
master_timeout    与master node建立连接超时时间,默认30秒
timeout    response的超时时间,默认30秒
wait_for_active_shards    等待活动分片的数量,默认为0
wait_for_events    等待指定队列的优先级处理完成后返回,可选immediate, urgent, high, normal, low, languid
wait_for_no_initializing_shards    是否等待没有initializations的分片时返回,默认false表示不等待
wait_for_no_relocating_shards    是否等待不存在relocating的分片时返回,默认false表示不等待
wait_for_nodes    指定可用的节点数N,(>=N, <=N, >N 以及 <N等)
wait_for_status    等待集群变成指定状态后返回, green, yellow , red,默认不等待任何状态

出参

{
    "cluster_name": "docker-cluster",//集群名字
    "status": "green",//集群状态
    "timed_out": false,//监控查询是否超时,默认超时时间为30秒
    "number_of_nodes": 3,//集群中所有节点数量
    "number_of_data_nodes": 3,//集群中数据节点数量
    "active_primary_shards": 11,//集群中活动的主分片数
    "active_shards": 22,//集群中活动的总分片数
    "relocating_shards": 0,//正在从一个节点迁往其他节点总的分片数
    "initializing_shards": 0,//集群中处在initializing状态分片的数量,索引刚创建时分片的状态
    "unassigned_shards": 0,//集群中处在unassigned状态分片的数量,表示集群不健康,有分片未被分配
    "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": 100.0//集群中活动分片的占比
}

集群状态说明

(1).green:每个索引的primary shard和replica shard都是active状态的。

(2).yellow:每个索引的primary shard都是active状态的,但是部分replica shard不是active状态,处于不可用的状态。

(3).red:不是所有索引的primary shard都是active状态的,部分索引有数据丢失了

参考:https://blog.csdn.net/gaoliang1719/article/details/124240087

posted @ 2019-02-24 17:17  意犹未尽  阅读(325)  评论(0编辑  收藏  举报