Elasticsearch（四）集群高可用讲解

ゝ一世哀愁。 2022-02-04 02:43 173阅读 0赞

**目录**

1、集群监控

2、添加索引

3、横向扩展

4、继续扩展

5、应对故障

# 1、集群监控 #

集群健康（Cluster health）包括三种状态：green、yellow、red。

<table style="width:500px;"> 
 <thead> 
  <tr> 
   <th>颜色</th> 
   <th>意义</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>green</td> 
   <td>所有主要分片和复制分片都可用</td> 
  </tr> 
  <tr> 
   <td>yellow</td> 
   <td>&nbsp;所有主要分片可用，但不是所有复制分片都可用</td> 
  </tr> 
  <tr> 
   <td>red</td> 
   <td>&nbsp;不是所有的主要分片都可用</td> 
  </tr> 
 </tbody> 
</table>

命令：

http://10.24.54.241:9200/_cluster/health/

结果：

{
    cluster_name: "my-application",
    status: "green",
    timed_out: false,
    number_of_nodes: 2,
    number_of_data_nodes: 2,
    active_primary_shards: 0,
    active_shards: 0,
    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
    }

# 2、添加索引 #

索引（index）——一个存储关联数据的地方。索引只是一个用来指向一个或多个分片的逻辑命名空间。

一个分片是一个最小级别“工作单元”，它只是保存了索引中所有数据的一部分。

分片是 Elasticsearch 在集群中分发数据的关键。把分片想象成数据的容器。文档存储在分片中，然后分片分配到你集群中的节点上。当你的集群扩容或缩小，Elasticsearch 将会自动在你的节点间迁移分片，以使集群保持平衡。

分片分为主分片和复制分片。索引中的每个文档属于一个独立的主分片，所以主分片的数量决定了索引最多能存储多少数据。

复制分片只是主分片的一个副本，它可以放置硬件故障导致的数据丢失，同时可以提供读请求，比如搜索或从别的分片取回文档。

当索引创建完成的时候，主分片的数量就固定了，但是复制分片的数量可以随时调整。

**举例：创建一个 blogs 的索引。**

分配3个主分片和一个复制分片（每个主分片都有一个复制分片）。

运行命令：

curl -H "Content-Type: application/json" -XPUT 'http://10.24.54.241:9200/blogs' -d '{"settings" : {"number_of_shards" : 3,"number_of_replicas" : 1}}'

创建成功再次访问：[http://10.24.54.241:9200/\_cluster/health/?pretty][http_10.24.54.241_9200_cluster_health_pretty]

结果：

{
    cluster_name: "my-application",
    status: "green",
    timed_out: false,
    number_of_nodes: 2,
    number_of_data_nodes: 2,
    active_primary_shards: 3,
    active_shards: 6,
    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
    }

结果显示：有六个活跃分片（三个主分片、三个复制分片）

![20190506195103867.png][]

# 3、横向扩展 #

随着应用需求的增长，我们启动第三个节点

![20190506195137475.png][]

`    分片会被重新分配以平衡负载：Node3`包含了分别来自`Node 1`和`Node 2`的一个分片，这样每个节点就有两个分片，和之前相比少了一个，这意味着每个节点上的分片将获得更多的硬件资源（CPU、RAM、I/O）。

分片本身就是一个完整的搜索引擎，它可以使用单一节点的所有资源。我们拥有6个分片（3个主分片和三个复制分片），最多可以扩展到6个节点，每个节点上有一个分片，每个分片可以100%使用这个节点的资源。

# 4、继续扩展 #

PUT /blogs/_settings
    {
       "number_of_replicas" : 2
    }

复制分片的数量增加到 2，这是blogs 索引就有 9个分配：3个主和3个复制分片。这意味着我们可以扩展为 9个节点，每个分片一个节点，这样使我们搜索性能比三个节点提升3倍。

# 5、应对故障 #

杀掉节点1的集群如下图：

![20190506195522490.png][]

节点1是主节点，这是需要选举一个新的主节点：节点2

主分片 1 和 2 在我们杀掉节点1时已经丢失，我们的索引在丢失主分片时不能正常故障。这是集群健康是 red：不是所有主分片都可用！

幸运的是丢失的两个主分片的**完整拷贝**存在于其他节点上，所以新主节点做的第一件事是把这些在`Node 2`和`Node 3`上的复制分片**升级为主分片**，这时集群健康回到`yellow`状态。这个提升是瞬间完成的，就好像按了一下开关。

为什么集群健康状态是`yellow`而不是`green`？我们有三个主分片，但是我们指定了每个主分片对应两个复制分片，当前却只有一个复制分片被分配，这就是集群状态无法达到`green`的原因，不过不用太担心这个：**当我们杀掉`Node 2`**，我们的程序依然可以在没有丢失数据的情况下继续运行，因为`Node 3`还有每个分片的拷贝。

如果我们重启`Node 1`，集群将能够重新分配丢失的复制分片，集群状况与上一节的 **图5：增加number\_of\_replicas到2** 类似。如果`Node 1`依旧有旧分片的拷贝，它将会尝试再利用它们，它只会从主分片上复制在故障期间有数据变更的那一部分。

[http_10.24.54.241_9200_cluster_health_pretty]: http://10.24.54.241:9200/_cluster/health/?pretty
[20190506195103867.png]: /images/20220204/c76a9932fbd84a12a5c9e99ff06af75d.png
[20190506195137475.png]: /images/20220204/f535778b80de40ffb0c8d498d9b48a4f.png
[20190506195522490.png]: /images/20220204/a88a4521232e4176b092cbbcfe4224aa.png