Stay Hungry.Stay Foolish.
初窥Elasticsearch集群

Elasticsearch集群提供了强大的容灾能力,任意一个节点故障都不会影响数据完整性,节点故障之后,只要现存节点存在一份完整index, es就能在短时间内复制一份完整index作为副本均衡到各个节点应对下次故障。

基本原理

在ES工作的时候,主节点会监控所有的节点是否正常,默认配置为:节点每隔1s主节点会发送1次心跳,超时时间为30s,测试次数为3次,超过3次,则认为该节点同主节点已经脱离了。如果某一个节点出现问题,ES认为这个节点损坏,该节点会从集群中删除,并且ES会重新平衡整个集群。

测试观察平衡过程

下图是我的集群,4个节点都放在本机 ES的数据存储有主分片和副本两份(默认的副本数量是1,可以更改index.number_of_replicas来修改副本数量),上图我的content_engine索引配置了15个分片,加上副本就会有30个分片,就是30个小方块!颜色比较深的是主分片的数据分片,比较淡的是副本的数据分片。可以看到每个节点的个数分别是7、7、8、8分配,比较平均,应该是为了性能上的负载均衡,同时两个相同的分片永远在两个不同的节点,不然还谈什么容灾呢,是吧哈哈。

我这里随意kill掉一个节点,集群的健康状态开始变为黄色,等一会又会恢复健康的绿色,这个过程的时间等于主节点发现节点损坏,然后开始复制数据备份的时间总和,所以容灾能力依赖于你各个节点直接网络的通信状况和机器的硬件性能,这个时间总和越短,容灾能力就越强。 这个过程开个wireshark抓包看看数据复制的过程。 data字段就是数据了,里面关键字就可以看到index/shared/recov。这个data应该有ES特定的协议来解包,就留下次分析吧。同时可以看到数据复制通过TCP端口。 下图是集群恢复之后 现在的分片分布变成了10、10、10,ES集群已经进行了自动平衡,3个节点的数据和依然是2份完整的数据。

容灾能力有多强?

如何破坏这个集群,如果在第一个节点损坏的时候,集群还没有重新平衡完毕,中间又有节点损坏,那么数据很可能就会丢失,这个时候只能重新启动集群了。这里我观察0分片所在的节点,我同时kill掉这两个节点(在es-02和es-03节点上),0分片就丢失了。在重启之前集群状态一直会是红色,代表数据丢失。

自由转载-非商用-非衍生-保持署名(创意共享3.0许可证
评论

暂无评论~~