干货 | Elasticsearch 运维实战常用命令清单

背景

球友反馈的实战问题:

关于es的运维相关的, 遇到一些问题!

  • 第一个问题:是关于集群迁移的,目前需要 针对20亿的数据做迁移,如果文件迁移,需要停机时间太久,除了重新灌入,不知 道有没有更好的方式?

  • 第二个问题:我们es集群的读写都很频繁,如何把控在相互不影响性能,当前情况是会有相互影响!

  • 第三个问题:之前做版本升级,升级后部分分片不可用,但是不知道什么原因导致?

  • 最后:就是关于数据的扩容,备份,高可用这方面...... 扩容其实 面对一个问题就是你之前的es  mapping 如何建, 如果这个没规划好,增加节点的意义也不大了

  • 另外就是面对现在集群状态黄色和红色,没有体系化的思路去排查问题到底出在哪儿?

更多的是点对点去临时解决,积累的知识是碎片化的。

的确,类似问题经常被问到,是时候整合梳理一下了。

1、集群状态非绿排查清单

1.1 集群状态的含义

  • 红色:至少一个主分片未分配成功;

  • 黄色:至少一个副本分片未分配成功;

  • 绿色:全部主&副本都分配成功。

1.2 排查实战

1.2.1 查看集群状态

GET _cluster/health

返回状态举例:"status" : "red", 红色,至少一个主分片未分配成功。

1.2.2 到底哪个节点出现了红色或者黄色问题呢?

GET _cluster/health?level=indices

如下的方式,更明快直接

GET /_cat/indices?v&health=yellow
GET /_cat/indices?v&health=red

找到对应的索引。

1.2.3 到底索引的哪个分片出现了红色或者黄色问题呢?

GET _cluster/health?level=shards

1.2.4 到底什么原因导致了集群变成红色或者黄色呢?

GET _cluster/allocation/explain

返回核心信息解读举例:

"current_state" : "unassigned",——未分配
  "unassigned_info" : {
    "reason" : "INDEX_CREATED",——原因,索引创建阶段
    "at" : "2020-01-29T07:32:39.041Z",
    "last_allocation_status" : "no"
  },
  "explanation" : """node does not match index setting [index.routing.allocation.require] filters [box_type:"hot"]"""
        }

根本原因,shard分片与节点过滤类型不一致 到此,找到了根本原因,也就知道了对应解决方案。

1.3 扩展思考:类似 "current_state" : "unassigned",——未分配 还有哪些?

实战:

GET _cat/shards?h=index,shard,prirep,state,unassigned.reason

官网:https://www.elastic.co/guide/en/elasticsearch/reference/7.2/cat-shards.html

未分配状态及原因解读:

(1)INDEX_CREATED
Unassigned as a result of an API creation of an index.
(2)CLUSTER_RECOVERED
Unassigned as a result of a full cluster recovery.
(3)INDEX_REOPENED
Unassigned as a result of opening a closed index.
(4)DANGLING_INDEX_IMPORTED
Unassigned as a result of importing a dangling index.
(5)NEW_INDEX_RESTORED
Unassigned as a result of restoring into a new index.
(6)EXISTING_INDEX_RESTORED
Unassigned as a result of restoring into a closed index.
(7)REPLICA_ADDED
Unassigned as a result of explicit addition of a replica.
(8)ALLOCATION_FAILED
Unassigned as a result of a failed allocation of the shard.
(9)NODE_LEFT
Unassigned as a result of the node hosting it leaving the cluster.
(10)REROUTE_CANCELLED
Unassigned as a result of explicit cancel reroute command.
(11)REINITIALIZED
When a shard moves from started back to initializing, for example, with shadow replicas.
(12)REALLOCATED_REPLICA
A better replica location is identified and causes the existing replica allocation to be cancelled.

2、节点间分片移动

适用场景:手动移动分配分片。将启动的分片从一个节点移动到另一节点。

POST /_cluster/reroute
{
  "commands": [
    {
      "move": {
        "index": "indexname",
        "shard": 1,
        "from_node": "nodename",
        "to_node": "nodename"
      }
    }
  ]
} 

3、集群节点优雅下线

适用场景:保证集群颜色绿色的前提下,将某个节点优雅下线。

PUT /_cluster/settings
{
  "transient": {
    "cluster.routing.allocation.exclude._ip": "122.5.3.55"
  }
}

4、强制刷新

适用场景:刷新索引是确保当前仅存储在事务日志中的所有数据也永久存储在Lucene索引中。

POST /_flush

注意:这和 7.6 版本之前的同步刷新(未来8版本+会废弃同步刷新)一致。

POST /_flush/synced

5、更改并发分片的数量以平衡集群

适用场景:

控制在集群范围内允许多少并发分片重新平衡。默认值为2。

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

6、更改每个节点同时恢复的分片数量

适用场景:

如果节点已从集群断开连接,则其所有分片将都变为未分配状态。经过一定的延迟后,分片将分配到其他位置。每个节点要恢复的并发分片数由该设置确定。

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

7、调整恢复速度

适用场景:

为了避免集群过载,Elasticsearch限制了分配给恢复的速度。你可以仔细更改该设置,以使其恢复更快。

如果此值调的太高,则正在进行的恢复可能会消耗过多的带宽和其他资源,这可能会使集群不稳定。

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

8、清除节点上的缓存

适用场景:如果节点达到较高的JVM值,则可以在节点级别上调用该API 以使 Elasticsearch 清理缓存。

这会降低性能,但可以使你摆脱OOM(内存不足)的困扰。

POST /_cache/clear

9、调整断路器

适用场景:为了避免在Elasticsearch中进入OOM,可以调整断路器上的设置。这将限制搜索内存,并丢弃所有估计消耗比所需级别更多的内存的搜索。

注意:这是一个非常精密的设置,你需要仔细校准。

PUT /_cluster/settings
{
  "persistent": {
    "indices.breaker.total.limit": "40%"
  }
}

10、集群迁移

适用场景:集群数据迁移、索引数据迁移等。

方案一、 针对索引部分或者全部数据,reindex

POST _reindex
{
  "source": {
    "index": "my-index-000001"
  },
  "dest": {
    "index": "my-new-index-000001"
  }
}

方案二:借助第三方工具迁移索引或者集群

  • elasticdump

  • elasticsearch-migration

工具本质:scroll + bulk 实现。

11、集群数据备份和恢复

适用场景:高可用业务场景,定期增量、全量数据备份,以备应急不时之需。

PUT /_snapshot/my_backup/snapshot_hamlet_index?wait_for_completion=true
{
  "indices": "hamlet_*",
  "ignore_unavailable": true,
  "include_global_state": false,
  "metadata": {
    "taken_by": "mingyi",
    "taken_because": "backup before upgrading"
  }
}

POST /_snapshot/my_backup/snapshot_hamlet_index/_restore

小结

文章开头的几个运维问题已经解决,其他性能相关的问题,后面会有另外的博文做梳理。

运维工作包罗万象,文章内容只是抛砖引玉,开了个头。

牛逼的集群运维需要结合可视化工具(如:kibana,cerebro,elastic-hd,Prometheus + grafana,结合业务自研工具如 阿里云Eyou等)能极大提高效率。

你的Elasticsearch 运维的经验、心得、体会,欢迎留言交流,我们一起完善清单。


参考:

Elasticsearch 官方文档 

https://logz.io/blog/elasticsearch-cheat-sheet/ 

更多推荐:

严选 | Elasticsearch史上最全最常用工具清单

干货 | Elasticsearch Top10 监控指标

短时间快习得多干货!

中国近 1/4 的 Elastic认证工程师出自于此!

©️2020 CSDN 皮肤主题: Age of Ai 设计师:meimeiellie 返回首页