标签：shards shard primary 索引 replica Elasticsearch 集群 ES
内容目录
1.搭建Kibana
正如《Kibana 用户手册》中所介绍，Kibana 是一款开源的数据分析和可视化平台，因此我们可以借助 Kibana 来与Elasticsearch（简称ES） 交互。
下载并解压：
cd /usr/local
wget https://artifacts.elastic.co/downloads/kibana/kibana-6.6.1-linux-x86_64.tar.gz
tar -zxvf kibana-6.6.1-linux-x86_64.tar.gz -C .
启动Kibana：
cd kibana-6.6.1-linux-x86_64/
bin/kibana
Kibana 所指向ES的地址默认为localhost，该配置在config/kibana.yml，若需要修改，可修改该配置文件。
Kibana 启动成功，我们便可以在 Dev Tools菜单下的Console中写 ES命令了，Kibana 的其他功能我们以后再做介绍。
2.集群健康
在进行索引操作之前，我们有必要先了解一下 ES集群的健康情况，这将有助于我们看懂索引操作的命令执行之后的运行结果。
查看集群的健康情况：GET _cluster/health
结果：
{
"cluster_name" : "elasticsearch",
"status" : "green",
"timed_out" : false,
"number_of_nodes" : 1,
"number_of_data_nodes" : 1,
"active_primary_shards" : 1,
"active_shards" : 1,
"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.0
}
从结果中我们可以看出当前集群的健康情况为 green，active_shards_percent_as_number 为 100.0，两者什么意思呢，有没有必然的联系呢？答案当然是有的。
正常情况下，集群的健康状态分为green、yellow、red三种。
- green：每个Index的primary shard （即shard）和replica shard（即replica）都是active状态，都已经分配好。集群100%可用
- yellow：每个Index的primary shard均为active状态，但至少还有一个replica shard不是active状态。此时数据没有丢失，集群仍然可用
- red：至少一个primary shard不是active状态，它的全部replica shard也已缺失。此时数据已经发生了丢失，搜索时只会返回部分的数据
当集群状态非green时，我们可以使用 GET _cluster/health?level=indices 命令查看各个Index的细节，进而定位具体哪一个索引出现了问题，以便解决问题。
输出中的relocating_shards为0表明当前没有分片正在从一个节点迁移至其他节点。为什么会出现分片迁移这种情况呢？因为ES是一个分布式搜索分析引擎，而分布式往往对应着海量数据，ES实现了shard负载均衡的功能，当添加新节点或者下线已有节点时，ES的集群发现机制会自动将shard进行均匀分配（由ES中的 decider 决定，它们是ES中作出分配决定的最高指挥，当使用多个decider 时，若其中一个decider通过投票不赞成重新分配一个分片，那该分片就不能移动了），以保证各个节点上的shard 数几乎相等，可以均衡的处理各种请求。所以一般情况下relocating_shards的值均为0。
那么什么情况下会出现initializing_shards不为0的情况呢？节点刚刚重启时、刚刚创建分片时等。
unassigned_shards又是一个什么状态呢？就是分片已经在集群状态中，但是在实际集群中你又找不到这个分片。例如：两个节点，一共有2个primary shard，每个primary shard又有两个replica shard，假设节点1中存在primary shard R0、replica shard R1，节点2中存在primary shard R1，replica shard R0，那么此时就会有2个replica shard未分配，因为replica shard既不能和自己的primary shard在同一个节点，又不能够和自己的primary shard的其他replica shard在同一个节点上（even_shard分片分配器决定），此时unassigned_shards就为2。一般未分配的分片都是replica shard。
此外，我们也可以借助ES的cat API查看集群的健康情况，不过cat API的输出结果并不是以json格式返回的，而是以不带表头的表格形式返回的，为了方便理解，我们可以通过添加参数v来将表头也输出出来。GET _cat/health?v
结果：
3.索引操作
- 查询索引：
GET _cat/indices?v
结果：
从结果中我们可以看到索引的健康情况、状态、索引名称、uuid、primary shard个数、replica shard个数、document 个数、被标记为deleted的document 的个数，索引大小、primary shard大小。
- 创建索引：
PUT /indexName
在创建索引时可以指定primary shard的个数，也可以指定一个primary shard配置几个replica shard。若不指定，则默认一个索引 10个shard，其中5个primary shard，5个replica shard，即使是单节点环境也会如此，这种就是典型的over allocation。如果你知道明确的要放入ES 中的数据集，最好在创建索引时指定一下所需的primary shard 个数及其replica shard个数；否则则需要根据节点数来做决定。
举例：创建索引order，并指定其包含3个primary shard，每个primary shard配置2个replica shard：
PUT /orders
{
"settings": {
"number_of_shards": 3,
"number_of_replicas": 2
}
}
一旦索引创建成功，则primary shard的个数就不能再修改了，replica shard的个数随时可以修改。因为ES是根据下面的路由算法来计算得出该document 应该存放在哪个shard 中的，为了保证在搜索document 时得出与存放时相同的路由值，故一旦索引创建成功，则primary shard的个数不能再修改。shard = hash(routing) % number_of_primary_shards
当对document 进行增删改查操作时，默认会带一个routing 值，这个值默认为document 的_id，当然也可以通过routing参数指定routing的值。
每个document 仅会存在于一个primary shard 及其 replica shard中，不同primary shard 上保存的document 都是不同的。
当数据量特别大，需要扩容时，我们一般采用水平扩容的方式，即采购更多相同配置的服务器，而非采用垂直扩容的方式，即增加容量更大、配置更高的服务器。之所以采用水平扩容，一是成本问题，二是使用更多的服务器，可以将shard分散到更多的node上，提高了系统的容错性，每个node上拥有更少的shard，那么cpu等资源也可以分配更多到shard上，三是易于以后再次扩容。
- 删除索引：
DELETE /indexName
如果这篇文章对你有帮助或启发，欢迎关注和转发，你的关注和转发是对我最大的支持。
如果你有什么疑问想要免费vip服务，欢迎扫描下方二维码，关注即可获得1v1免费vip服务。
标签：shards,shard,primary,索引,replica,Elasticsearch,集群,ES 来源： https://www.cnblogs.com/mengyi/p/10800595.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。