Elasticsearch 横向扩容以及容错机制

写在前面的话:读书破万卷,编码如有神
--------------------------------------------------------------------

参考内容:

  《Elasticsearch顶尖高手系列-快速入门篇》,中华石杉

--------------------------------------------------------------------

主要内容包括:

  • 横向扩容
  • 容错机制

--------------------------------------------------------------------

1、Elasticsearch横向扩容

1.1、primary shard 和 replica shard自动负载均衡

目前情况:2个node, 3个primary shard,3个replica shard

如果此时给es集群增加一个节点(node),es会自动对primary shard和replica shard进行负载均衡

1.2、每个Node有更少的shard, IO/CPU/Memory资源给每个shard分配更多,每个shard性能更好

1.3、扩容的极限,6个shard(3个primary shard,3个replica shard),最多扩容到6台机器,每个shard可以占用单台服务器的所有资源,性能最好

--------------------------------------------------------------------

2、Elasticsearch容错机制

2.1、master选举、replica容错、数据恢复

目前es集群情况:3个node,9个shard(3个primary shard,6个replica shard)

如果此时master node宕机:

因为Node1节点宕机了,所以primary shard0、replica shard1、replica shard2三个3shard就丢失了。master node宕机的一瞬间,primary shard0这个shard就没有了,此时就不是active status,所以集群的状态为red.

容错第一步:master选举,自动选举另外一个node成为新的master,承担起master的责任来

容错第二步:新master将丢失的primary shard的某个replica shard提升为primary shard,此时cluster status会变为Yellow,因为所有的primary shard都变成了active status,但是,少了一个replica shard,所以不是所有的replica shard都是active。

容错第三步:重启故障的node, new master节点将会把缺失的副本都copy一份到该node上去,而且该node会使用之前已有的shard数据,只是同步一下宕机之后发生的改变。

此时es cluster的状态为green,因为所有的primary shard和replica shard都是active状态。

--------------------------------------------------------------------

原文地址:https://www.cnblogs.com/xinhuaxuan/p/8450094.html

时间: 2024-10-11 07:34:26

Elasticsearch 横向扩容以及容错机制的相关文章

Elasticseach的横向扩展、容错机制(3)

1.横向扩容过程,如何超出扩容极限,以及如何提升容错性 (1)primary&replica自动负载均衡,6个shard,3 primary,3 replica (2)每个node有更少的shard,IO/CPU/Memory资源给每个shard分配更多,每个shard性能更好 (3)扩容的极限,6个shard(3 primary,3 replica),最多扩容到6台机器,每个shard可以占用单台服务器的所有资源,性能最好 (4)超出扩容极限,动态修改replica数量,9个shard(3pr

(32)ElasticSearch的容错机制

ElasticSearch的容错机制处理过程 以9个shard,3个节点为例,如果master节点宕机,此时不是所有的primary shard都是Active status,所以此时的集群状态是red. 容错处理的第一步:重新选举一台服务器作为master 容错处理的第二步:新选举的master会把宕掉的primary shard的某个replica shard提升为primary shard,此时集群状态为yellow,因为少了一个replica shard,并不是所有的replica sh

架构师之路--搜索业务和技术介绍及容错机制

今天和搜索部门一起做了一下MQ的迁移,顺便交流一下业务和技术.发现现在90后小伙都挺不错.我是指能力和探究心.我家男孩,不招女婿. 在前面的文章中也提到,我们有媒资库(乐视视频音频本身内容)和全网作品库(外部视频音频内容),数据量级都在千万级.我们UV,PV,CV,VV都是保密的.所以作为一个合格的员工来说………………数值我也不知道.总之,这些数据作为最终数据源,要走一个跨多个部门的工作流才最终出现在用户点击搜索按钮出现的搜索框里.大体流程图如下: 这个流程图之所以没像以往一样手绘,嗯,那是因为

12.横向扩容 、提升容错性

主要知识点: 横向扩容后shard的自动分配及自动负载均衡 扩容极限及超过扩容极限后的处理 不同情况下的容错. 1.横向扩容 当扩容时,es会自动进行负载均衡,也就是会自动的分配primary shard 和replica shard 到新增加的node中.从而保证:每个node上有大致相同的shard数量(primary shard 和replica shard 一定是要存放在不同的node中的)此时,每个node有更少的shard,因此每个shard 可以占用这个node更多的资源(IO/C

Flink状态管理和容错机制介绍

本文主要内容如下: 有状态的流数据处理: Flink中的状态接口: 状态管理和容错机制实现: 阿里相关工作介绍: 一.有状态的流数据处理# 1.1.什么是有状态的计算# 计算任务的结果不仅仅依赖于输入,还依赖于它的当前状态,其实大多数的计算都是有状态的计算. 比如wordcount,给一些word,其计算它的count,这是一个很常见的业务场景.count做为输出,在计算的过程中要不断的把输入累加到count上去,那么count就是一个state. 1.2.传统的流计算系统缺少对于程序状态的有效

es 容错机制

1.图解Elasticsearch容错机制:master选举,replica容错,数据恢复 (1)9 shard,3 node(2)master node宕机,自动master选举,red(3)replica容错:新master将replica提升为primary shard,yellow(4)重启宕机node,master copy replica到该node,使用原有的shard并同步宕机后的修改,green 原文地址:https://www.cnblogs.com/siye1989/p/1

ack是什么,如何使用Ack机制,如何关闭Ack机制,基本实现,STORM的消息容错机制,Ack机制

1.ack是什么 ack 机制是storm整个技术体系中非常闪亮的一个创新点. 通过Ack机制,spout发送出去的每一条消息,都可以确定是被成功处理或失败处理, 从而可以让开发者采取动作.比如在Meta中,成功被处理,即可更新偏移量,当失败时,重复发送数据. 因此,通过Ack机制,很容易做到保证所有数据均被处理,一条都不漏. 另外需要注意的,当spout触发fail动作时,不会自动重发失败的tuple,需要spout自己重新获取数据,手动重新再发送一次 ack机制即, spout发送的每一条消

RDD之七:Spark容错机制

引入 一般来说,分布式数据集的容错性有两种方式:数据检查点和记录数据的更新. 面向大规模数据分析,数据检查点操作成本很高,需要通过数据中心的网络连接在机器之间复制庞大的数据集,而网络带宽往往比内存带宽低得多,同时还需要消耗更多的存储资源. 因此,Spark选择记录更新的方式.但是,如果更新粒度太细太多,那么记录更新成本也不低.因此,RDD只支持粗粒度转换,即只记录单个块上执行的单个操作,然后将创建RDD的一系列变换序列(每个RDD都包含了他是如何由其他RDD变换过来的以及如何重建某一块数据的信息

【Spark】Spark容错机制

引入 一般来说,分布式数据集的容错性有两种方式:数据检查点和记录数据的更新. 面向大规模数据分析,数据检查点操作成本很高,需要通过数据中心的网络连接在机器之间复制庞大的数据集,而网络带宽往往比内存带宽低得多,同时还需要消耗更多的存储资源. 因此,Spark选择记录更新的方式.但是,如果更新粒度太细太多,那么记录更新成本也不低.因此,RDD只支持粗粒度转换,即只记录单个块上执行的单个操作,然后将创建RDD的一系列变换序列(每个RDD都包含了他是如何由其他RDD变换过来的以及如何重建某一块数据的信息