Elasticsearch系列文章目录
- Elasticsearch学习笔记(一)Elasticsearch2.4.2安装
- Elasticsearch学习笔记(二)Elasticsearch入门
- Elasticsearch学习笔记(三)Elasticsearch5.1.2安装
- Elasticsearch学习笔记(四)版本控制[并发安全]
- Elasticsearch学习笔记(五)批量操作
- Elasticsearch学习笔记(六)Elasticsearch分布式集群值helloWord
- Elasticsearch学习笔记(七)Elasticsearch分布式集群工作原理简介
集群信息查看
查看集群健康值
我们在前面的文章中介绍了简历一个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-3
kill掉:
刚开始的时候是yellow状态,不过主分片都正常,可以正常对外提供服务,主节点也切换到了node-2
过一小会,再看一下,发现集群一切正常了:
故障切换的过程对我们是完全透明的。再重新启动node-3
节点,可以观察一下集群的变化。
对于集群,初步写到这里,后续会详细写一下其内部实现,其实和redis集群也差不多。