《从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服务。