elasticsearch之节点重启

节点离开

在elasticsearch集群中,假设NodeA因为种种原因退出集群,在NodeA上的Shard分片情况(ShardA是主分片,ShardB是某一分片副本):

  1. 在存活节点上找到ShardA的副本,将该副本升格为主分片
  2. 由于ShardB这一分片副本丢失,所以会重新创建相应的分片副本
  3. 在存活的节点中对于分片进行再平衡
    这样做的目的是保证每个分片都有足够的副本,可以避免数据丢失。需要注意的是,步骤二和步骤三牵涉到大量的网络I/O操作。

节点返回

如果离开的节点重新加入集群,elasticsearch为了对数据分片(shard)进行再平衡,会为重新加入的NodeA再次分配数据分片(Shard), 这会再次导致大量的网络I/O操作。

延迟副本的重新分配

如果NodeA在离开前上面存在副本ShardB,重新加入之后还是有副本ShardB,看起来一样,但其实中间已经进行了大量的网络I/O,那么有没有办法延迟副本的重新分配呢,这样会冒丢失数据的可能(如果在NodeA重新加入之前,其它节点也挂了), 但是可以节省相应的网络开销。

延迟副本分配可以通过设置参数index.unassigned.node_left.delayed_timeout来实现,该参数动态可调,默认值是1分钟(1m)

PUT /_all/_settings
{
  "settings": {
    "index.unassigned.node_left.delayed_timeout": "5m"
  }
}

上述脚本将副本重新分配延迟到5分钟之后。

查看数据分片分布情况

使用elasticsearch中的marvel插件可以很清楚的看到数据分片的分布情况,选取marvel中右上角 DashBoard 中的 Shard Allocation , 可以看到类似于下图的分布情况:

更多选项

如果日常维护elasticsearch集群,针对某一节点进行需要重启的更改,那么可以先禁止分片分配,待重启完成后,再打开:

PUT _cluster/setting
{
    "cluster.routing.allocation.disable_allocation": true
}

避免节点重启导致的脑裂

如果elasticsearch集群中节点数比较多,而且负载也比较高,这个时候对某一个instance进行重启,很有可能会导致该instance无法找到master而将自己推举为master的情况出现,如何防止,需要调整 elasticsearch.yml 中的内容:

discovery.zen.minimum_master_nodes: 2
discovery.zen.ping.timeout: 120s
discovery.zen.ping.multicast.enabled: false
discovery.zen.ping.unicast.hosts: ["host1","host2"]

client.transport.ping_timeout: 60s

加快recovery的进程

Elasticsearch在默认情况下将资源更多的分配给正常的traffic,这样给recovery的资源相对有限,会导致整个集群长时间处于yellow状态,如果机器配置很强劲,那么更改如下配置,可以加快elasticsearch instance重启之后的恢复过程。

cluster.routing.allocation.node_initial_primaries_recoveries: 10
cluster.routing.allocation.node_concurrent_recoveries: 5
indices.recovery.max_bytes_per_sec: 100mb
indices.recovery.concurrent_streams: 5
时间: 2024-10-21 13:47:37

elasticsearch之节点重启的相关文章

容器服务节点重启操作最佳实践

直接重启节点可能会导致集群出现异常.比如,对于 Swarm Mode 集群内的 Manager 节点,如果 Manager 健康节点数小于 2,则可能会导致集群无法自愈,最终导致集群不可用.本文结合阿里云历史案例经验,说明了在对容器服务进行主动运维等场景下,需要重启节点时的操作最佳实践. 检查业务高可用配置 在重启容器服务节点前,建议先检查或修正如下业务配置,以避免节点重启触发单点异常,进而导致业务可用性受损: 1. 配置数据持久化策略 建议为日志.业务配置等重要数据配置外部卷进行数据持久化,以

为什么 elasticsearch 获取节点信息失败?

问题描述 为什么 elasticsearch 获取节点信息失败? 在 spring boot 项目中即成集成 elasticsearch(dao层数据与es交互使用的的是 spring-data-elasticsearch)首先安装了服务器端的 es 服务,和 head 插件,es 服务启动正常,node-1 为默认主节点,my-cluster 为集群名,如图: 在程序中,使用嵌入式node启动节点正常,方式如下: Node node = NodeBuilder.nodeBuilder().no

mapid溢出导致Oracle RAC 节点重启的case

某客户的CRM数据库在2015年9月17号11:38分左出现其中一个节点宕机的情况.其中节点1报错信息如下: Thu Sep 17 11:38:10 2015 Use ADRCI or Support Workbench to package the incident. See Note 411.1 at My Oracle Support for error and packaging details. NOTE: ASMB terminating Errors in file /oracle

【RAC】单节点 重启 报ORA-1105 ORA-01606

版本 11.2.0.1.0 rac1   rac2   linux 5.3U  2.6.18-128.el5    因为要修复一个bug做测试,在一个节点上修改隐含参数,然后重启!在测试的过程中遇到 修改了rac1 上的参数 sys@rac1>alter system set "_gc_read_mostly_locking"=false scope=spfile sid='rac1'; sys@rac1>shutdown immedate Database closed.

11gR2 RAC重启后只能起单节点

11gR2 RAC重启后只能起单节点 问题背景: 将11gR2 RAC正常部署完成之后执行两节点重启操作发现其中有一个节点的集群资源无法启动,遂再次重启该无法启动集群资源的节点,还是不可.随即将正常节点重启发现原故障节点资源起来了,待重启完毕后原正常节点资源无法启动.   集群环境: OS:RedHat EnterPrise5.8 x86_x64 DB:Oracle EnterPrise Database 11.2.0.4.0 x86_x64 GRID:Oracle Grid Infrastru

ORACLE RAC环境下节点自动重启问题总结

文章参考:主要来源于网络资源分享,并结合自己的ORACLE RAC环境近段时间OS节点自动重启问题进行分析总结 首先我们对能够导致节点重启的CRS进程进行介绍.1.ocssd : 它的主要功能是节点监控(Node Monitoring)和组管理(Group Management),它是CRS的核心进程之一.节点监控是指监控集群中节点的健康状况,监控的方法是通过网络心跳(network heartbeat)和磁盘心跳(disk heartbeat)实现的,如果集群中的节点连续丢失磁盘心跳或网络心跳

redis分布式锁,无须设置有效期,自动检测hold锁的节点是否存活

1.有一个独立的keeplive守护线程保证节点存活,频率是n. 2.节点存活信息由固定前置+mac+进程id+进程启动时间,保证节点重启问题. 3. 锁的信息由固定前置+mac+进程id+进程启动时间. 4. 具体锁的逻辑参考lock方法. package six.com.crawler.common; import java.lang.management.ManagementFactory; import java.net.InetAddress; import java.net.Netw

ElasticSearch集群操作例子详解

rest 接口 现在我们已经有一个正常运行的节点(和集群),下一步就是要去理解怎样与其通信.幸运的是,Elasticsearch提供了非常全面和强大的REST API,利用这个REST API你可以同你的集群交互.下面是利用这个API,可以做的几件事情: 1.查你的集群.节点和索引的健康状态和各种统计信息 2.管理你的集群.节点.索引数据和元数据 3.对你的索引进行 CRUD(创建.读取.更新和删除)和搜索操作 4.执行高级的查询操作, 像是分页.排序.过滤.脚本编写(scripting).小平

Linux 关于Transparent Hugepages的介绍

透明大页介绍 Transparent Huge Pages的一些官方介绍资料: Transparent Huge Pages (THP) are enabled by default in RHEL 6 for all applications. The kernel attempts to allocate hugepages whenever possible and any Linux process will receive 2MB pages if the mmap region is