ElasticSearch自愈之节点丢失恢复

数据库 其他数据库
ElasticSearch集群由于业务压力过大,有时会OOM,导致集群节点crash掉,在无主机资源增加时,该脚本解决了在收到告警而手工拉起ES节点的困惑,对业务用户来说也相对透明,通过该脚本受到一定的启发,在对于现网环境,可以不断的对特殊场景进行自愈,以保障运维的稳定性。

点击上方“IT那活儿”公众号,关注后了解更多内容,不管IT什么活儿,干就完了!!!

背 景

Elasticsearch是一个开源的、分布式的、高可用的、实时的搜索和分析引擎,它有助于快速收集、存储和分析大量数据,广泛应用于大规模数据的实时搜索和分析。

而在现实运维中,随着业务的扩展,数据量不断增大,为保障业务性能,ES集群不断的扩容节点,扩大集群,有的集群多达上百个节点,虽集群内部具有副本冗余机制,但由于PCSERVER的不稳定性(磁盘故障、网络故障、硬件BUG、内核、内部错误等)或集群的性能压力或程序Bug,可能会导致集群节点丢失。

目前我们运维已经做到7*24短信告警监控,只是在大半夜,有可能无法即时收到短信进行恢复,为能即时恢复集群状态,进而对节点丢失场景研究,并编写自动化脚本,定义autocron task自动恢复集群。

下面是我们的一个业务的集群,由于业务压力,经常性会丢失1~2个节点,并基于该场景做自动恢复。

场景介绍

2.1 脚本设计思路

图片

  • 集群节点数统计,对节点的数量统计,节点数不同则设置不同的值,根据实际情况设置;
  • 对剩余节点判断,小于3则对节点直接拉起;
  • 等待5分钟,可根据实际情况调整,对集群状态进行判断。

目前该场景权适用于部分节点丢失的情况,由于考虑主机硬件问题导致的所有节点故障,存在主机PING告警,在主机重启后,进行判断后再拉起,在未来可对这一块进一步调整优化。

2.2 具体脚本

#!/bin/bas
MONITOR_HOME="/app/check_es"
app_home="/app"
hostip="xxxxxxxx"
node="node_xxxxxxx_9200"
node_number1=`curl -u username:xxxxxxxx http://xxxxxxxx:9200/_cat/nodes|grep 'xxxxxxxx'|wc -l`
if [ ${node_number1} -ne 5 ];then
curl -u username:xxxxxxxx http://xxxxxxxx:9200/_cat/nodes?v |grep 'xxxxxxxx'|awk '{print $10}' > $MONITOR_HOME/now.txt
grep -vwf $MONITOR_HOME/now.txt $MONITOR_HOME/last.txt > $MONITOR_HOME/check.txt
if [[ ${node_number1} < 3 ]];then
cd $MONITOR_HOME
./mess.sh -b "`date` $hostip ERROR: 丢失节点数超过3个,请检查" -t 18974885939,1536793399
else
if [[ ${node_number1} > 2 ]];then
for i in `cat ${MONITOR_HOME}/check.txt`
do
echo "`date` 节点${i}异常,准备重启" >> ${MONITOR_HOME}/error.log
if [ ${i} = ${node} ];then
pid=`ps -ef |grep ${i} |grep -v grep|grep -v controller|grep -v node_${hostip}_9201|grep -v node_${hostip}_9202|grep -v node_${hostip}_9203|grep -v node_${hostip}_9204|awk '{print $2}'`
else
pid=`ps -ef |grep ${i} |grep -v grep|grep -v controller|awk '{print $2}'`
fi
if [ !${pid} ];then

kill -9 ${pid}
cd ${app_home}/${i}/elasticsearch
./bin/elasticsearch -d
else
cd ${app_home}/${i}/elasticsearch
./bin/elasticsearch -d
fi
done
sleep 300s
node_number2=`curl -u username:xxxxxxxx http://xxxxxxxx:9200/_cat/nodes|grep 'xxxxxxxx'|wc -l`
node_status=`curl -u username:xxxxxxxx http://xxxxxxxx:9200/_cat/health|awk '{print $4}'`
if [ ${node_number2} -ne 5 ];then
echo "节点未恢复,请检查"
else
if [[ ${node_status} = "red" ]];then
echo "节点已重新加入集群,正在恢复"
else
echo "集群已恢复"
fi
fi
fi
fi
fi

自愈带来的成效:

ElasticSearch集群由于业务压力过大,有时会OOM,导致集群节点crash掉,在无主机资源增加时,该脚本解决了在收到告警而手工拉起ES节点的困惑,对业务用户来说也相对透明,通过该脚本受到一定的启发,在对于现网环境,可以不断的对特殊场景进行自愈,以保障运维的稳定性。

责任编辑:武晓燕 来源: IT那活儿
相关推荐

2010-07-20 15:01:39

SQLServer日志

2018-05-04 09:25:47

2010-04-19 15:53:20

Oracle重做日志

2011-03-04 14:59:16

Raidoracle数据库

2011-05-24 10:26:12

Oracle数据库日志文件

2018-01-24 09:03:45

恢复丢失删除

2010-04-12 14:25:04

Oracle备份

2022-12-28 08:16:16

metric聚合java

2011-03-22 16:20:19

恢复数据库

2010-04-06 10:11:11

Oracle备份

2022-02-25 08:02:41

集群ceph16集群恢复

2018-06-15 10:07:32

Windows 10Windows回收站

2011-03-23 09:31:26

归档日志文件数据库恢复

2018-04-28 14:55:41

Windows 10升级恢复

2017-06-06 15:24:13

springElasticSear架构

2024-06-26 19:14:53

2010-05-06 09:42:28

Oracle表空间

2010-06-30 10:55:13

SQL Server日

2014-10-08 09:51:12

ios8漏洞文件安全

2023-08-25 09:39:38

数据库Oracle
点赞
收藏

51CTO技术栈公众号