【原创】《从0开始学Elasticsearch》—集群健康和索引管理

内容目录

1.搭建Kibana2.集群健康3.索引操作

1.搭建Kibana

正如《Kibana 用户手册》中所介绍,Kibana 是一款开源的数据分析和可视化平台,因此我们可以借助 Kibana 来与Elasticsearch(简称ES) 交互。

下载并解压:

cd /usr/local
wget https://artifacts.elastic.co/downloads/kibana/kibana-6.6.1-linux-x86_64.tar.gz
tar -zxvf kibana-6.6.1-linux-x86_64.tar.gz -C .

启动Kibana:

cd kibana-6.6.1-linux-x86_64/
bin/kibana

Kibana 所指向ES的地址默认为localhost,该配置在config/kibana.yml,若需要修改,可修改该配置文件。
Kibana 启动成功,我们便可以在 Dev Tools菜单下的Console中写 ES命令了,Kibana 的其他功能我们以后再做介绍。

2.集群健康

在进行索引操作之前,我们有必要先了解一下 ES集群的健康情况,这将有助于我们看懂索引操作的命令执行之后的运行结果。

查看集群的健康情况:
GET _cluster/health
结果:

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

从结果中我们可以看出当前集群的健康情况为 green,active_shards_percent_as_number 为 100.0,两者什么意思呢,有没有必然的联系呢?答案当然是有的。

正常情况下,集群的健康状态分为green、yellow、red三种。

  • green:每个Index的primary shard (即shard)和replica shard(即replica)都是active状态,都已经分配好。集群100%可用
  • yellow:每个Index的primary shard均为active状态,但至少还有一个replica shard不是active状态。此时数据没有丢失,集群仍然可用
  • red:至少一个primary shard不是active状态,它的全部replica shard也已缺失。此时数据已经发生了丢失,搜索时只会返回部分的数据

当集群状态非green时,我们可以使用 GET _cluster/health?level=indices 命令查看各个Index的细节,进而定位具体哪一个索引出现了问题,以便解决问题。

输出中的relocating_shards为0表明当前没有分片正在从一个节点迁移至其他节点。为什么会出现分片迁移这种情况呢?因为ES是一个分布式搜索分析引擎,而分布式往往对应着海量数据,ES实现了shard负载均衡的功能,当添加新节点或者下线已有节点时,ES的集群发现机制会自动将shard进行均匀分配(由ES中的 decider 决定,它们是ES中作出分配决定的最高指挥,当使用多个decider 时,若其中一个decider通过投票不赞成重新分配一个分片,那该分片就不能移动了),以保证各个节点上的shard 数几乎相等,可以均衡的处理各种请求。所以一般情况下relocating_shards的值均为0。
那么什么情况下会出现initializing_shards不为0的情况呢?节点刚刚重启时、刚刚创建分片时等。

unassigned_shards又是一个什么状态呢?就是分片已经在集群状态中,但是在实际集群中你又找不到这个分片。例如:两个节点,一共有2个primary shard,每个primary shard又有两个replica shard,假设节点1中存在primary shard R0、replica shard R1,节点2中存在primary shard R1,replica shard R0,那么此时就会有2个replica shard未分配,因为replica shard既不能和自己的primary shard在同一个节点,又不能够和自己的primary shard的其他replica shard在同一个节点上(even_shard分片分配器决定),此时unassigned_shards就为2。一般未分配的分片都是replica shard。

此外,我们也可以借助ES的cat API查看集群的健康情况,不过cat API的输出结果并不是以json格式返回的,而是以不带表头的表格形式返回的,为了方便理解,我们可以通过添加参数v来将表头也输出出来。
GET _cat/health?v
结果:
【原创】《从0开始学Elasticsearch》—集群健康和索引管理

3.索引操作

  • 查询索引:
    GET _cat/indices?v
    结果:
    【原创】《从0开始学Elasticsearch》—集群健康和索引管理

从结果中我们可以看到索引的健康情况、状态、索引名称、uuid、primary shard个数、replica shard个数、document 个数、被标记为deleted的document 的个数,索引大小、primary shard大小。

  • 创建索引:
    PUT /indexName
    在创建索引时可以指定primary shard的个数,也可以指定一个primary shard配置几个replica shard。若不指定,则默认一个索引 10个shard,其中5个primary shard,5个replica shard,即使是单节点环境也会如此,这种就是典型的over allocation。如果你知道明确的要放入ES 中的数据集,最好在创建索引时指定一下所需的primary shard 个数及其replica shard个数;否则则需要根据节点数来做决定。

举例:创建索引order,并指定其包含3个primary shard,每个primary shard配置2个replica shard:

PUT /orders
{
  "settings": {
    "number_of_shards": 3,
    "number_of_replicas": 2
  }
}

一旦索引创建成功,则primary shard的个数就不能再修改了,replica shard的个数随时可以修改。因为ES是根据下面的路由算法来计算得出该document 应该存放在哪个shard 中的,为了保证在搜索document 时得出与存放时相同的路由值,故一旦索引创建成功,则primary shard的个数不能再修改。
shard = hash(routing) % number_of_primary_shards
当对document 进行增删改查操作时,默认会带一个routing 值,这个值默认为document 的_id,当然也可以通过routing参数指定routing的值。

每个document 仅会存在于一个primary shard 及其 replica shard中,不同primary shard 上保存的document 都是不同的。

当数据量特别大,需要扩容时,我们一般采用水平扩容的方式,即采购更多相同配置的服务器,而非采用垂直扩容的方式,即增加容量更大、配置更高的服务器。之所以采用水平扩容,一是成本问题,二是使用更多的服务器,可以将shard分散到更多的node上,提高了系统的容错性,每个node上拥有更少的shard,那么cpu等资源也可以分配更多到shard上,三是易于以后再次扩容。

  • 删除索引:
    DELETE /indexName

如果这篇文章对你有帮助或启发,欢迎关注和转发,你的关注和转发是对我最大的支持。
如果你有什么疑问想要免费vip服务,欢迎扫描下方二维码,关注即可获得1v1免费vip服务。

![](https://img2018.cnblogs.com/blog/1046121/201905/1046121-20190501200458386-602033933.jpg)

上一篇:win10 设置声卡驱动 --- 解决喇叭没有声音!


下一篇:windows消息机制(MFC)