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

小咪咪 2022-07-11 12:17 237阅读 0赞

### 文章目录 ###

*  Elasticsearch系列文章目录
 *  集群信息查看
 *   *  查看集群健康值
     *   *  通过head插件看
         *  通过URL请求查看
     *  查看节点信息
     *  查看所有索引信息
 *  索引与分片
 *  扩容
 *  动态修改副本数量
 *  故障处理

# Elasticsearch系列文章目录 #

*  [Elasticsearch学习笔记（一）Elasticsearch2.4.2安装][Elasticsearch_Elasticsearch2.4.2]
 *  [Elasticsearch学习笔记（二）Elasticsearch入门][Elasticsearch_Elasticsearch]
 *  [Elasticsearch学习笔记（三）Elasticsearch5.1.2安装][Elasticsearch_Elasticsearch5.1.2]
 *  [Elasticsearch学习笔记（四）版本控制\[并发安全\]][Elasticsearch]
 *  [Elasticsearch学习笔记（五）批量操作][Elasticsearch 1]
 *  [Elasticsearch学习笔记（六）Elasticsearch分布式集群值helloWord][Elasticsearch_Elasticsearch_helloWord]
 *  [Elasticsearch学习笔记（七）Elasticsearch分布式集群工作原理简介][Elasticsearch_Elasticsearch 1]

# 集群信息查看 #

## 查看集群健康值 ##

我们在前面的文章中介绍了简历一个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`\*\*含义说明

<table> 
 <thead> 
  <tr> 
   <th>颜色</th> 
   <th>说明</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td><code>green</code></td> 
   <td>所有主要分片和复制分片都可用</td> 
  </tr> 
  <tr> 
   <td><code>yellow</code></td> 
   <td>所有主要分片可用，但不是所有复制分片都可用</td> 
  </tr> 
  <tr> 
   <td><code>red</code></td> 
   <td>不是所有的主要分片都可用</td> 
  </tr> 
 </tbody> 
</table>

## 查看节点信息 ##

[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个分片，每个分片又有一个副本，副本分布另一个节点上。

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

鼠标点击`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节点中：  
![这里写图片描述][SouthEast 1]

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

# 故障处理 #

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

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

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

[Elasticsearch_Elasticsearch2.4.2]: https://blog.csdn.net/liubenlong007/article/details/54695168
[Elasticsearch_Elasticsearch]: https://blog.csdn.net/liubenlong007/article/details/54695167
[Elasticsearch_Elasticsearch5.1.2]: https://blog.csdn.net/liubenlong007/article/details/54708107
[Elasticsearch]: https://blog.csdn.net/liubenlong007/article/details/54729129
[Elasticsearch 1]: https://blog.csdn.net/liubenlong007/article/details/54729136
[Elasticsearch_Elasticsearch_helloWord]: https://blog.csdn.net/liubenlong007/article/details/54729148
[Elasticsearch_Elasticsearch 1]: https://blog.csdn.net/liubenlong007/article/details/54729164
[SouthEast]: /images/20220711/89452b4e73ed48789b91f84a2ea3eb9e.png
[SouthEast 1]: /images/20220711/eba6379acc6d43dd878a198821bd543b.png
[SouthEast 2]: /images/20220711/9d382771cba44dc0a071c010f0edabe3.png
[SouthEast 3]: /images/20220711/24780174a1984137837cd02cdbe22cf8.png