【原创】《从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
结果：

3.索引操作

• 查询索引：
  GET _cat/indices?v
  结果：
  

从结果中我们可以看到索引的健康情况、状态、索引名称、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服务。