Elasticsearch学习笔记（六）Elasticsearch分布式集群值helloWord

集群信息查看

查看集群健康值

我们在前面的文章中介绍了简历一个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集群也差不多。