Elasticsearch学习笔记(六)Elasticsearch分布式集群值helloWord

Elasticsearch系列文章目录

集群信息查看

查看集群健康值

我们在前面的文章中介绍了简历一个ES集群,现在就是用这个集群进行说明。

通过head插件看

进入head插件,第一行右侧会显示 es-cluster集群健康值: green (90 of 90)

通过URL请求查看

GET请求/_cluster/health:

{
    "cluster_name": "es-cluster",
    "status": "green",
    "timed_out": false,
    "number_of_nodes": 3,
    "number_of_data_nodes": 3,
    "active_primary_shards": 45,
    "active_shards": 90,
    "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
}

以上命令与curl -XGET 'http://10.104.29.19:9211/_cat/health?v'作用相同:

[root@vm-29-19-pro01-bgp whatslive-api]#  curl -XGET 'http://10.104.29.19:9211/_cat/health?v'
epoch      timestamp cluster    status node.total node.data shards pri relo init unassign pending_tasks max_task_wait_time active_shards_percent 
1485310242 10:10:42  es-cluster green           3         3     90  45    0    0        0             0                  -                100.0% 

**status**含义说明

颜色说明
green所有主要分片和复制分片都可用
yellow所有主要分片可用,但不是所有复制分片都可用
red不是所有的主要分片都可用

查看节点信息

[root@vm-29-19-pro01-bgp whatslive-api]#  curl -XGET 'http://10.104.29.19:9211/_cat/nodes?v'
host         ip           heap.percent ram.percent load node.role master name   
10.104.29.19 10.104.29.19            3          93 0.16 d         m      node-2 
10.104.29.19 10.104.29.19           14          93 0.16 d         *      node-3 
10.104.29.19 10.104.29.19            7          93 0.16 d         m      node-1 

从上面结果可以看到,ES集群中的节点分为主节点(master)从节点(flower)节点,上面ndoe-3是master节点,另外两个是从。
集群中一个节点会被选举为
主节点(master)
,它将临时管理集群级别的一些变更,例如新建或删除索引、增加或移除节点等。主节点不参与文档级别的变更或搜索,这意味着在流量增长的时候,该主节点不会成为集群的瓶颈。任何节点都可以成为主节点。我们例子中的集群只有一个节点,所以它会充当主节点的角色。

做为用户,我们能够与集群中的任何节点通信,包括主节点。每一个节点都知道文档存在于哪个节点上,它们可以转发请求到相应的节点上。我们访问的节点负责收集各节点返回的数据,最后一起返回给客户端。这一切都由Elasticsearch处理。

查看所有索引信息

[root@vm-29-19-pro01-bgp whatslive-api]#  curl -XGET 'http://10.104.29.19:9211/_cat/indices?v'
health status index                                 pri rep docs.count docs.deleted store.size pri.store.size 
green  open   megacorp                                5   1          3            0     25.3kb         12.6kb 
green  open   apilog_2017.01.23                       5   1       4098            0      4.1mb            2mb 
green  open   website                                 5   1          2            1     15.1kb          7.5kb 
green  open   logstash-nginx_lehi_access_2017.01.23   5   1        380            0      1.7mb          872kb 
green  open   luffi_log_2017.01.23                    5   1      14642            0     17.1mb          8.5mb 
green  open   .marvel-es-1-2017.01.24                 1   1     185398          528    188.5mb         94.3mb 
green  open   .marvel-es-1-2017.01.25                 1   1      18959           90       19mb          9.4mb 
green  open   .marvel-es-1-2017.01.23                 1   1     120761          456    125.9mb         62.9mb 
green  open   .kibana                                 1   1          1            0      6.3kb          3.1kb 
green  open   apierrorlog_2017.01.23                  5   1          8            0    134.4kb         67.2kb 
green  open   sc_apilog_2017.01.23                    5   1     339230            0    557.6mb          280mb 
green  open   .marvel-es-data-1                       1   1          7            1     17.4kb          8.7kb 
green  open   sc_apierrorlog_2017.01.23               5   1        630            0      1.2mb        636.7kb 

索引与分片

如果你了解redis集群的实现逻辑,那么理解ES集群就易如反掌了。

我们在使用ES集群的时候不需要关心实际的分片分布情况,因为ES已经为我们封装好了。但是我们还是有必要详细了解其内部工作原理,以便于可以更好的应用ES为我们服务。

我们前面提到的索引(index)——一个存储关联数据的地方,实际上,它只是一个用来指向一个或多个分片(shards)“逻辑命名空间(logical namespace)”

一个分片(shard)是一个最小级别“工作单元(worker unit)”,它只是保存了索引中所有数据的一部分。一个节点的数据可以有多个主分片(primary shard),并且可以有多个复制分片(replica shard),副本的存在作用是冗余备份横向扩容增加读取的效率。默认分片数量是5,副本数量是1,当然这些我们都可以修改。

下图展示了website索引在3个节点的分布情况。可以看到,总共分为了5个分片,每个分片又有一个副本,副本分布另一个节点上。

实际开发过程中不同节点会部署到不同机器甚至不同的机房中,为了安全可靠性。我们这里作为测试,就把所有节点全部部署在了一台机器上
这里写图片描述

鼠标点击node-1上的0号分片,显示内容:

{
    "state": "STARTED",
    "primary": true,
    "node": "ypHpZ6azSFmk6zYYDwTWrw",
    "relocating_node": null,
    "shard": 0,
    "index": "website",
    "version": 3,
    "allocation_id": {
        "id": "Z0Hh_XJiQm6kJQ_lYVwH8Q"
    }
}

鼠标点击node-2上的0号分片,显示内容:

{
    "state": "STARTED",
    "primary": false,
    "node": "rDCHmVZITc-ssGDiAAbP4A",
    "relocating_node": null,
    "shard": 0,
    "index": "website",
    "version": 3,
    "allocation_id": {
        "id": "F1m7ID8zRsOL6rgUc_AscQ"
    }
}

主要关心primary字段,true表示是主分片,FALSE表示是从分片。

扩容

ES的这种分片机制(现在主流的分布式解决方案)可以很方便的实现横向的扩容,大家可以自己测试一下ES节点从一个到三个一次递增的过程,观察其分片与备份的分布情况。

如果想扩容,只需要启动新的节点即可。注意cluster.name(请看./config/elasticsearch.yml文件)要相同,ES会自动在网络中查找相同cluster.name的集群并加入其中。如果没有加入请检查网络防火墙等是否正常。

动态修改副本数量

PUT请求/website/_settings,参数为:

{
   "number_of_replicas" : 2
}

执行命令,返回结果:

{
    "acknowledged": true
}

此时我们在查看website索引的分片以及副本分布情况,可以发现每一个分片都有3份(包括一个主,两个从),分不到不同node节点中:
这里写图片描述

注意,主分片的数量在初始创建索引确定以后,不可以更改!

故障处理

读者可以尝试kill掉其中某一个节点,观察集群中节点及分片的情况,我们现在吧node-3kill掉:
刚开始的时候是yellow状态,不过主分片都正常,可以正常对外提供服务,主节点也切换到了node-2
这里写图片描述
过一小会,再看一下,发现集群一切正常了:
这里写图片描述

故障切换的过程对我们是完全透明的。再重新启动node-3节点,可以观察一下集群的变化。

对于集群,初步写到这里,后续会详细写一下其内部实现,其实和redis集群也差不多。

已标记关键词 清除标记
©️2020 CSDN 皮肤主题: Age of Ai 设计师:meimeiellie 返回首页
实付 9.90元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值