发现方式

Zen discovery是内建的、默认的、用于Elasticsearch的发现模块。它提供了单播和基于文件的发现,可以通过插件扩展到支持云环境和其他形式的发现。

Zen Discovery 是与其他模块集成的,例如,节点之间的所有通信都使用 transport 模块完成。某个节点通过 发现机制 找到其他节点是使用 Ping 的方式实现的。

Zen Discovery 使用种子节点(seed nodes)列表来开始发现过程。在启动时,或者在选举新主节点的时候,Elasticsearch 会尝试连接到其列表中的每个种子节点,并与他们进行类似'闲聊'的对话,以查找其他节点并构建集群的完整成员图。

默认情况下,有两种方法可用于配置种子节点列表:单播基于文件。建议种子节点列表主要由集群中那些 Master-eligible 的节点组成。

Master-eligible:node.master设置为 true(默认)的节点,使其有资格被选为控制集群的主节点。

单播

单播发现 配置静态主机列表以用作种子节点。 可以将这些主机指定为 主机名IP地址。 指定为主机名的主机在每轮 ping 操作期间解析为 IP 地址。 请注意,如果您处于 DNS 解析随时间变化的环境中,则可能需要调整 JVM安全设置

可以在 elasticsearch.yml 配置文件中使用discovery.zen.ping.unicast.hosts静态设置设置主机列表。

discovery.zen.ping.unicast.hosts: ["host1", "host2"]

具体的值是一个主机数组或逗号分隔的字符串。每个值应采用host:porthost的形式(其中port默认为设置transport.profiles.default.port,如果未设置则返回transport.tcp.port)。 请注意,必须将IPv6主机置于括号内。 此设置的默认值为127.0.0.1,[:: 1]。

另外,discovery.zen.ping.unicast.resolve_timeout 配置在每轮ping操作中等待DNS查找的时间。需要指定时间单位,默认为5秒。

单播发现(unicast discovery)应用 transport 模块实现发现(discovery)。

基于文件

除了静态discovery.zen.ping.unicast.hosts 设置提供的主机之外,还可以通过外部文件提供主机列表。Elasticsearch在更改时会重新加载此文件,以便种子节点列表可以动态更改,而无需重新启动每个节点。例如,这为在Docker容器中运行的Elasticsearch实例提供了一种方便的机制,可以动态提供一个IP地址列表,以便在节点启动时无法知道这些IP地址时连接到Zen discovery。

要启用基于文件的发现,请file按如下方式配置hosts提供程序:

discovery.zen.hosts_provider:file

然后以$ES_PATH_CONF/unicast_hosts.txt下面描述的格式创建文件。每当对unicast_hosts.txt文件进行更改时,Elasticsearch都会选择新的更改,并使用新的主机列表。

请注意,基于文件的发现插件会增强单播主机列表 elasticsearch.yml:如果存在有效的单播主机条目, discovery.zen.ping.unicast.hosts则除了提供的那些之外,还将使用它们 unicast_hosts.txt。

discovery.zen.ping.unicast.resolve_timeout设置还适用于通过基于文件的发现由地址指定的节点的DNS查找。同样需要指定时间单位,默认为5秒。

该文件的格式是每行指定一个节点条目。每个节点条目由主机(主机名或IP地址)和可选的传输端口号组成。如果指定了端口号,必须在主机(在同一行)之后使用“:”分割。如果未指定端口号,则使用默认值9300。

例如,这是 unicast_hosts.txt 具有四个参与单播发现的节点的集群的示例,其中一些节点未在默认端口上运行:

10.10.10.5
10.10.10.6:9305
10.10.10.5:10005
# an IPv6 address
[2001:0db8:85a3:0000:0000:8a2e:0370:7334]:9301

允许使用主机名而不是IP地址(类似于 discovery.zen.ping.unicast.hosts)。必须在括号中指定IPv6地址,并在括号后面添加端口。

也可以为此文件添加注释,所有注释必须在每行的开头显示_#_(即注释不能在一行中间开始)。

选举主节点

作为 ping 过程的一部分,一个集群的主节点需要是被选举或者加入进来的(即选举主节点也会执行ping,其他的操作也会执行ping)。这个过程是自动执行的。通过配置discovery.zen.ping_timeout来控制节点加入某个集群或者开始选举的响应时间(默认3s)。

在这段时间内有3个 ping 会发出。如果超时,重新启动 ping 程序。在网络缓慢时,3秒时间可能不够,这种情况下,需要慎重增加超时时间,增加超时时间会减慢选举进程。

一旦节点决定加入一个存在的集群,它会发出一个加入请求给主节点,这个请求的超时时间由discovery.zen.join_time控制,默认是 ping 超时时间(discovery.zen.ping_timeout)的20倍。

当主节点停止或者出现问题,集群中的节点会重新 ping 并选举一个新节点。有时一个节点也许会错误的认为主节点已死,所以这种 ping 操作也可以作为部分网络故障的保护性措施。在这种情况下,节点将只从其他节点监听有关当前活动主节点的信息。

如果discovery.zen.master_election.ignore_non_master_pings设置为true时(默认值为false),node.masterfalse的节点不参加主节点的选举,同时选票也不包含这种节点。

通过设置node.masterfalse,可以将节点设置为非备选主节点,永远没有机会成为主节点。

discovery.zen.minimum_master_nodes设置了最少有多少个备选主节点参加选举,同时也设置了一个主节点需要控制最少多少个备选主节点才能继续保持主节点身份。如果控制的备选主节点少于discovery.zen.minimum_master_nodes个,那么当前主节点下台,重新开始选举。

discovery.zen.minimum_master_nodes必须设置一个恰当的备选主节点值(quonum,一般设置 为备选主节点数/2+1),尽量避免只有两个备选主节点,因为两个备选主节点quonum应该为2,那么如果一个节点出现问题,另一个节点的同意人数最多只能为1,永远也不能选举出新的主节点,这时就发生了脑裂现象。

集群故障检测

有两个故障检测进程在集群的生命周期中一直运行。一个是主节点的,ping集群中所有的其他节点,检查他们是否活着。另一种是每个节点都ping主节点,确认主节点是否仍在运行或者是否需要重新启动选举程序。

使用discovery.zen.fd前缀设置来控制故障检测过程,配置如下:

配置 描述
discovery.zen.fd.ping_interval 节点多久ping一次,默认1s
discovery.zen.fd.ping_timeout 等待响应时间,默认30s
discovery.zen.fd.ping_retries 失败或超时后重试的次数,默认3

集群状态更新

主节点是唯一一个能够更新集群状态的节点。主节点一次处理一个群集状态更新,应用所需的更改并将更新的群集状态发布到群集中的所有其他节点。当其他节点接收到状态时,先确认收到消息,但是不应用最新状态。如果主节点在规定时间(discovery.zen.commit_timeout ,默认30s)内没有收到大多数节点(discovery.zen.minimum_master_nodes)的确认,集群状态更新不被通过。

一旦足够的节点响应了更新的消息,新的集群状态(cluster state)被提交并且会发送一条消息给所有的节点。这些节点开始在内部应用新的集群状态。在继续处理队列中的下一个更新之前,主节点等待所有节点响应,直到超时(discovery.zen.publish_timeout,默认设置为30秒)。上述两个超时设置都可以通过集群更新设置api动态更改。

No master block

对于一个可以正常充分运作的集群来说,必须拥有一个活着的主节点和正常数量(discovery.zen.minimum_master_nodes个)活跃的备选主节点。discovery.zen.no_master_block设置了没有主节点时限制的操作。它又两个可选参数

  • all:所有操作均不可做,读写、包括集群状态的读写api,例如获得索引配置(index settings),putMapping,和集群状态(cluster state)api
  • write:默认为write,写操作被拒绝执行,基于最后一次已知的正常的集群状态可读,这也许会读取到已过时的数据。

discovery.zen.no_master_block,对于节点相关的基本api,这个参数是无效的,如集群统计信息(cluster stats),节点信息(node info),节点统计信息(node stats)。对这些api的请求不会被阻止,并且可以在任何可用节点上运行。

Elasticsearch 通关教程(六): 自动发现机制 - Zen Discoveryedit的更多相关文章

  1. Elasticsearch 通关教程(四): 分布式工作原理

    前言 通过前面章节的了解,我们已经知道 Elasticsearch 是一个实时的分布式搜索分析引擎,它能让你以一个之前从未有过的速度和规模,去探索你的数据.它被用作全文检索.结构化搜索.分析以及这三个 ...

  2. Elasticsearch入门教程(六):Elasticsearch查询(二)

    原文:Elasticsearch入门教程(六):Elasticsearch查询(二) 版权声明:本文为博主原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接和本声明. 本文链接:h ...

  3. Redis 哨兵节点之间相互自动发现机制(自动重写哨兵节点的配置文件)

    Redis的哨兵机制中,如果是多哨兵模式,哨兵节点之间也是可以相互感知的,各种搜索之后出来的是千篇一律的一个基础配置文件,在配置当前哨兵节点的配置文件中,并没有配置其他哨兵节点的任何信息.如下是一个哨 ...

  4. Elasticsearch通关教程(五):如何通过SQL查询Elasticsearch

    前言 这篇博文本来是想放在全系列的大概第五.六篇的时候再讲的,毕竟查询是在索引创建.索引文档数据生成和一些基本概念介绍完之后才需要的.当前面的一些知识概念全都讲解完之后再讲解查询是最好的,但是最近公司 ...

  5. Elasticsearch通关教程(一): 基础入门

    简介 Elasticsearch是一个高度可扩展的.开源的.基于 Lucene 的全文搜索和分析引擎.它允许您快速,近实时地存储,搜索和分析大量数据,并支持多租户. Elasticsearch也使用J ...

  6. Elasticsearch 通关教程(七): Elasticsearch 的性能优化

    硬件选择 Elasticsearch(后文简称 ES)的基础是 Lucene,所有的索引和文档数据是存储在本地的磁盘中,具体的路径可在 ES 的配置文件../config/elasticsearch. ...

  7. Elasticsearch 通关教程(二): 索引映射Mapping问题

    数据库建表的时候,我们的DDL语句一般都会指定每个字段的存储类型,例如:varchar,int,datetime等等,目的很明确,就是更精确的存储数据,防止数据类型格式混乱. CREATE TABLE ...

  8. Elasticsearch 通关教程(三): 索引别名Aliases问题

    业务问题 业务需求是不断变化迭代的,也许我们之前写的某个业务逻辑在下个版本就变化了,我们可能需要修改原来的设计,例如数据库可能需要添加一个字段或删减一个字段,而在搜索中也会发生这件事,即使你认为现在的 ...

  9. Elasticsearch之重要核心概念(cluster(集群)、shards(分配)、replicas(索引副本)、recovery(据恢复或叫数据重新分布)、gateway(es索引的持久化存储方式)、discovery.zen(es的自动发现节点机制机制)、Transport(内部节点或集群与客户端的交互方式)、settings(修改索引库默认配置)和mappings)

    Elasticsearch之重要核心概念如下: 1.cluster 代表一个集群,集群中有多个节点,其中有一个为主节点,这个主节点是可以通过选举产生的,主从节点是对于集群内部来说的.es的一个概念就是 ...

随机推荐

  1. Dubbo 支持哪些序列化协议?

    面试题 dubbo 支持哪些通信协议?支持哪些序列化协议?说一下 Hessian 的数据结构?PB 知道吗?为什么 PB 的效率是最高的? 面试官心理分析 上一个问题,说说 dubbo 的基本工作原理 ...

  2. Hadoop系列001-大数据概论

    本人微信公众号,欢迎扫码关注! 大数据概论 1.大数据概念 大数据(big data),指无法在一定时间范围内用常规软件工具进行捕捉.管理和处理的数据集合,是需要新处理模式才能具有更强的决策力.洞察发 ...

  3. Linux下Springboot解决`APR based Apache Tomcat Native library`提示

    最近转行做java,开发基于Springboot的项目,版本号为2.1.0.RELEASE. 启动应用,发现以下提示: The APR based Apache Tomcat Native libra ...

  4. 记一次尴尬的Java应用内存泄露排查

    这星期被线上JVM内存占用不断增大的问题所困扰,自己提出了一些假设,然后去实施验证都一一失败了,有一些经验和教训在这里分享下. 之所以是尴尬,是最后因为修复了另一个看似不相关的问题导致内存不再上升,但 ...

  5. .NET Core TDD 前传: 编写易于测试的代码 -- 构建对象

    该系列第1篇: 讲述了如何创造"缝".  "缝"(seam)是需要知道的概念. 本文是第2篇, 介绍的是如何避免在构建对象时写出不易测试的代码. 本文的概念性内 ...

  6. 『集群』006 Slithice 后期改进 和 Slithice可能存在的BUG

    Slithice 后期改进 和 Slithice可能存在的BUG Slithice 可能存在的 BUG: >Slithice 暂时 没有 对 循环调度 进行控制:不正确的 配置 可能导致 调度死 ...

  7. 全内存的redis用习惯了?那能突破内存限制类redis产品ssdb呢?

    首先说一下背景,在双十一的时候,我们系统接受X宝的订单推送,同事原先的实现方式是使用redis的List作为推送数据的承载,在非大促的场景下, 一切运行正常,内存占用大概3-4G,机器是16G内存.由 ...

  8. 【我们一起写框架】MVVM的WPF框架(四)—DataGrid

    前言 这个框架写到这里,应该有很多同学发现,框架很多地方的细节,其实是违背了MVVM的设计逻辑的. 没错,它的确是违背了. 但为什么明知道违背设计逻辑,还要这样编写框架呢? 那是因为,我们编写的是框架 ...

  9. jenkins实现以gitlab为代码仓库的构建

    简介 前一篇随笔是安装jenkins的过程,比较简单,这一次说一下用jenkins配置以gitlab为代码管理仓库的maven项目的完整个构建过程,以及我碰到的一些问题.由于是maven项目,所以我们 ...

  10. Java设计模式---ChainOfResponsibility责任链模式

    参考于 : 大话设计模式 马士兵设计模式视频 代码参考于马士兵设计模式视频 写在开头:职责链模式:使多个对象都有机会处理请求,从而避免请求的发送者和接收者之间的耦合关系 图来自大话设计模式,下面我的代 ...