干货 | 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=yellowGET/_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":"""nodedoesnotmatchindexsetting[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_CREATEDUnassignedasaresultofanAPIcreationofanindex.（2）CLUSTER_RECOVEREDUnassignedasaresultofafullclusterrecovery.（3）INDEX_REOPENEDUnassignedasaresultofopeningaclosedindex.（4）DANGLING_INDEX_IMPORTEDUnassignedasaresultofimportingadanglingindex.（5）NEW_INDEX_RESTOREDUnassignedasaresultofrestoringintoanewindex.（6）EXISTING_INDEX_RESTOREDUnassignedasaresultofrestoringintoaclosedindex.（7）REPLICA_ADDEDUnassignedasaresultofexplicitadditionofareplica.（8）ALLOCATION_FAILEDUnassignedasaresultofafailedallocationoftheshard.（9）NODE_LEFTUnassignedasaresultofthenodehostingitleavingthecluster.（10）REROUTE_CANCELLEDUnassignedasaresultofexplicitcancelreroutecommand.（11）REINITIALIZEDWhenashardmovesfromstartedbacktoinitializing,forexample,withshadowreplicas.（12）REALLOCATED_REPLICAAbetterreplicalocationisidentifiedandcausestheexistingreplicaallocationtobecancelled. 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":"backupbeforeupgrading"}}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认证工程师出自于此！ 本文分享自微信公众号 - 铭毅天下（elastic999）。如有侵权，请联系 support@oschina.cn 删除。本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。
