每一个shard都需要有个家 - JAVA - 编程开发
设为首页 加入收藏

TOP

每一个shard都需要有个家(一)
2018-04-30 06:06:46 】 浏览:157
Tags:一个 shard 需要

这是一篇译文,原文(Every shard deserves a home)于2016-11-11发布在elastic官方博客。译文稍有更改

阅读提示

  1. 文章包含很多gif动图,你可以使用“2345看图王”查看/暂停/回放gif动图的每一帧
  2. 所有图片都可以在新标签页中查看大图
  3. “索引”有时作动词,有时作名词。例如“当索引第一个文档到新的索引中时…”,第一个索引是动词,第二个索引是名词
  4. 术语及翻译。有些术语不翻译,直接使用英文原词
rebalance 重新平衡
relocation 重新安置。即:集群已经选定了目标shard,需要从primary shard向这个目标shard复制数据
reallocation 重新分配。即:集群把某个/ 些索引的shard分布到集群中节点上
shard allocation shard分配
shard copy 分片副本(即可以是primary shard也可以是replica shard)
master master(主节点。使用英文原词,不再翻译)
shard shard(分片。使用英文原词,不再翻译)
primary shard primary shard(主分片。使用英文原词,不再翻译)
replica shard replica shard(副分片。使用英文原词,不再翻译)
segment segment(段,Lucene中的概念。使用英文原词,不再翻译)

文章正文开始

文中这些优秀的幻灯片来自于Core Elasticsearch: Operations课程,它们有助于解释shard分配(shard allocation)的概念。我们推荐您参加完整课程以更好的理解这些概念,但,我会在此列出培训的梗概

Shard分配(shard allocation)是把shard分配给节点的过程。 当初始恢复(initial recovery)、副分片分配(replica allocation)、重新平衡(rebalancing)或向集群中加入/移除节点时就会发生shard分配。大部分时间,你无需挂心它,它在后台由elasticsearch完成。如果你发现自己对这些细节感到好奇,这篇博客将探索几种不同场景下的shard分配

本文的集群由4个节点组成,如下图所示。文中的例子都使用此集群完成

我们将覆盖四种不同的场景

场景一、 创建索引

如上图所示,这是最简单的用例。我们创建了索引c,于是我们必须得为它分配新的shard。当索引第一个文档到这个新的索引时,就会为它分配shard。上图使用Kinaba中的Console插件(之前称为Sense)来执行灰色高亮的命令,索引一个文档到索引中

对于索引c,我们正在创建一个primary shard和一个replica shard。master需要创建索引c,并为它分配2个shard,即一个primary shard和一个replica shard。集群会通过以下方式来平衡集群

  1. 考察集群中每个节点所包含shard的平均数量,然后,尽可能使得每个节点上的此数字保持一致
  2. 基于集群中每一个索引来做评估,使得shard跨所有索引而保持平衡

Shard分配过程中存在一些限制,分配决定器(allocation decider)在做分配时会遵从这些限制。分配决定器会评估集群要做的每一个决定,并给出yes/no的回复。分配决定器运行在master上。你可以认为是master给出修改提议,分配决定器则告知master此修改提议是否能通过。

关于此最简单的一个例子就是,你不能把同一个shard的primary shard和replica shard放到同一个节点上

关于此还有一些其他例子

1. 基于Hot/Warm配置作分配过滤

这允许你把shard只放到具有特定属性的节点上,分配决定器会根据Hot/Warm配置接受或拒绝集群所作的决定。这是用户决定直接控制分配决定器的例子

2. 磁盘使用情况分配器(Disk usage allocator

master监控集群中磁盘的使用情况,并根据高水位/低水位阈值控制shard分配(见下面的:“场景二、 是时候移动shard了”)

3. 抑制(Throttles

这意味着,理论上我们可以把shard分配到某节点,但,此节点上有太多正在进行中的恢复(recovery)。为了保护节点并且也允许恢复进行,分配决定器让集群进行等待,然后在下一个迭代中再重试把shard分配给同一个节点

Shard初始化

一旦我们做出了primary shard将分配到哪个节点的决定,这个shard的状态就被标注为”initializing”(正在初始化),并且这个决定会通过一个modified ClusterState广播到集群中所有节点,然后集群中所有节点都将应用这个ClusterState

在shard状态被标注为”initializing”后,会进行如下动作。如下面动图所示

  1. 被选中的节点探测到它自己被分配了一个新的shard
  2. 在被选中的节点上,将创建一个空的lucene索引(译注:每一个shard都是一个独立的lucene索引),创建完成后被选中的节点向master发送“shard已经就绪”的通知
  3. master收到通知后,master需要把被选中的节点上shard的状态标注”started”,为了做到这一点,master发送一个modified ClusterState
  4. 被选中的节点收到master发送的modified ClusterState,于是被选中的节点激活此shard,并把shard的状态标注为”started”

因为这是一个primary shard,自此,我们就可以向其索引文档了

正如你所见,所有的通信都是通过modified ClusterState进行的。一旦这个周期结束,master会执行re-route,重新评估shard分配,有可能对先前迭代中被抑制的内容做出决定

现在,master要分配剩下的replica shard c0了,这也是由分配决定器来作决定的。分配决定器必须得等到包含primary shard的节点把primary shard的状态标注为”started”后,才能开始分配replica shard c0。如下图所示,primary shard c0已经在node2上分配完成且状态已经被标注为”started”,现在master需要分配剩下的replica shard c0了,replica shard c0的状态是unassigned

 

此时,会进行重新平衡,过程就和前面所描述的一样,重新平衡的目的是使数据在集群中是平衡的。在当前例子中,集群将把replica shard c0分配到node3,以使得集群是平衡的。最终,集群中每个节点包含3个shard。如下面两幅图所示,重新平衡把replilca shard c0分配给了node node3

 

 

上例子中,我们只是创建了一个空的replica shard,这比,假设说已经存在某个状态为”started”且包含数据的primary shard,要简单。对于这种情况,我们必须得确保新的
编程开发网

首页 上一页 1 2 3 4 下一页 尾页 1/4/4
】【打印繁体】【投稿】【收藏】 【推荐】【举报】【评论】 【关闭】 【返回顶部
上一篇Kafka 源码分析2 : Network相关 下一篇高并发风控技术解密(下)

评论

帐  号: 密码: (新用户注册)
验 证 码:
表  情:
内  容:

最新文章

热门文章

C 语言

C++基础

windows编程基础

linux编程基础

C/C++面试题目