ElasticSearch集群RED处理方案记录

前言

集群重新启动时会自动恢复不健康分区
此时GREEN的索引直接可以正常使用，YELLOW和RED的索引会逐步恢复
recovery期间，丢失数据的节点CPU会飙升，磁盘I/O也会飙升，恢复所需的时间与数据量有关
为了尽量减少对线上业务的影响，需要设置一些参数

禁用主从片复制，数据恢复会重新rebalance，禁用主从片复制可以减少磁盘I/O

PUT _cluster/settings
{
"persistent": {
"cluster": {
"routing": {
"allocation.enable": "none"
}
}
}
}

设置数据恢复时的吞吐量，不对外提供服务可以设置无限，对外提供服务时需考虑，SSD建议100mb~200mb

PUT _cluster/settings
{
"transient": {
"indices.recovery.max_bytes_per_sec" : "50mb"
}
}

设定分片恢复时的并发数，设置过高会导致死锁，过低恢复的会很慢，最好跟CPU数量一致

PUT _cluster/settings
{
"transient": {
"cluster.routing.allocation.node_concurrent_recoveries" : "2"
}
}

集群最多有6个分片在进行重新部署

PUT _cluster/settings
{
"transient": {
"cluster_concurrent_rebalance" : "6"
}
}

同步刷新API:

POST 索引/_flush/synced

ES数据分为冷数据和热数据两部分，冷数据在做恢复时速度较快

对一个索引五分钟内没有写操作会变为冷数据

POST stat/_flush/synced

重启ES集群

启用主从片复制

PUT _cluster/settings
{
"persistent": {
"cluster": {
.0
"routing": {
"allocation.enable": "all"
}
}
}
}

设置更改上述配置之前先查看ES当前配置

如果不是自己搭建的服务，比如租用的AWS或者阿里的服务

会根据购买的大小自动设置这些属性

根据情况设置这些参数

下面提供一些查看ES健康状态和设置的API

查看集群状态

GET _cluster/health?pretty

查看集群设置，可以看到es集群每个索引及其分片的健康状态

GET _cluster/settings

查看集群recovery情况

GET _cat/recovery?v

查看每个分片的状态，确定需要恢复的索引

GET _cluster/health?level=shards

下面两张图片记录了数据恢复当天es集群的资源使用情况，凌晨五点左右shutdown了集群，快6点的时候集群开始恢复，恢复完成在12点半左右

kibana1.png

kibana2.png

参考网站

命令参考https://www.elastic.co/guide/en/elasticsearch/reference/6.7/