ES运维--快速重启_运维_SouthPark的专栏-CSDN博客

标签: | 发表时间:2020-05-01 08:01 | 作者:
出处:https://blog.csdn.net
启动初始化时间长

修改es配置,重启集群成本巨大。ES集群已有25T数据,27个节点,24个数据节点(热盘12和hot节点,慢盘12个stale节点,3个mater节点),数据节点的启动,加入集群后需要初始化全部索引,这个过程过程很慢。全部重启一次可能要一天,非常耗时。重启后经常遇到少量索引一直处于unassigned状态,导致集群一直是red状态。

目标

有时调整配置,希望能快速重启生效(能用api改的优先不停服务修改),减少es服务停顿时间。
master节点和stale节点修改配置可以随时重启。
hot数据节点最好在晚上或者周末重启,重启前最好先停止数据写入。

发现启动前如果事先关闭shard自动均衡,初始化索引速度会快得多。因此我们完善了下操作流程

调整后的重启流程

A. 重启master节点
注意事项:先把非当选的两个master重启(可以同时操作);重启完成后,能在集群里看到两个点都加入后,才能重启最后一个master。master不需要恢复索引,没有初始化,速度很快。

B. 重启stale节点

注意事项:避开索引删除、索引迁移等定时任务执行时间段(如果时间有重叠,可先禁用调度任务)
1. 先关闭集群的shard分配(停止后新建索引将不会分配,index不能迁移,不会执行自动均衡)

      curl -XPUT http://ip:port/_cluster/settings -d '{"transient":{"cluster.routing.allocation.enable":"none"}}'

2. 备份配置文件,修改好所有配置(做好检查,不要漏)
3. 第一步执行完后,要查看es集群状态 curl 'ip:port/_cat/health?v'。等到relo、init、unassign这3项都变成0后,再操作下一步。(这个时间一定要等,磨刀不误砍柴功,这个操作完成后对重启初始化索引速度会大幅提高)
4. 重启节点。索引都初始化好了,再操作下一个节点。注意:不同物理机上的节点可以同时重启(最好不要同时启动太多节点,慢盘上的分片多初始化时间会稍长些),但不要在同一个物理机上同时重启多个节点。
节点启动后首先会找master加入集群,之后初始化本地索引分片数据,这个过程是CPU和IO密集型操作。
由于禁用了路由均衡分配,这个过程会比以前快得多。
5. 全部完成后要恢复分片分配

      curl -XPUT http://ip:port/_cluster/settings -d '{"persistent":{"cluster.routing.allocation.enable":"all"}}'
curl -XPUT http://ip:port/_cluster/settings -d '{"transient":{"cluster.routing.allocation.enable":"all"}}'

C. 重启hot节点
注意事项:避开索引创建、索引迁移等定时任务执行时间段(如果时间有重叠,可先禁用调度任务),在低峰操作(晚上或者周末)
1. 先停止所有数据写入
2. 后续操作和重启stale节点相同

D. 重启整个集群
顺序是先启master组(所有的master重启完成后要停止集群的shard自动均衡),再启hot组节点,最后启stale组节点

相关 [es 运维 重启] 推荐:

ES运维--快速重启_运维_SouthPark的专栏-CSDN博客

- -
修改es配置,重启集群成本巨大. ES集群已有25T数据,27个节点,24个数据节点(热盘12和hot节点,慢盘12个stale节点,3个mater节点),数据节点的启动,加入集群后需要初始化全部索引,这个过程过程很慢. 全部重启一次可能要一天,非常耗时. 重启后经常遇到少量索引一直处于unassigned状态,导致集群一直是red状态.

ES集群重启最佳实践 - 简书

- -
单index大小:20GB ~ 40GB. 索引数(按天拆分索引):600. 直接kill掉节点,可能导致数据丢失. 集群会认为该节点挂掉了,集群重新分配数据进行数据转移(shard rebalance),会导致节点直接大量传输数据. 节点重启之后,恢复数据,同样产生大量的磁盘、网络流量,耗费机器和网络资源的.

ES优化总结

- - 非技术 - ITeye博客
最近一直在研究ES集群,也看了很多篇前辈们总结的博客,同事借鉴了官方给出的一些建议,做了一下几点总结,希望对后来者有用:. 为了防止ES进程的内存被置换到磁盘上(会导致在检索的时候发生内存交换导致检索速度迟缓)引起性能急速下降. 候可以把config/elasticsearch.yml中的bootstrap.mlockall设置为true就可以了.

es的连接查询

- - 行业应用 - ITeye博客
在一般的关系型数据库中,都支持连接操作. 在ES这种分布式方案中进行连接操作,代价是十分昂贵的. 不过ES也提供了相类似的操作,支持水平任意扩展,实现连接的效果. 其他内容, 参考Elasticsearch官方指南整理. 在ES中支持两种连接方式:嵌套查询 和 has_child、has_parent父子查询.

ES性能优化总结

- - 互联网 - ITeye博客
    Elasticsearch是目前大数据领域最热门的技术栈之一,经过近8年的发展,已从0.0.X版升级至6.X版本,虽然增加了很多的特性和功能,但是在主体架构上,还是没有太多的变化. 下面就把我对于ES使用实践的一些经验总结一下,供大家参考;也请大家拍砖. 如果有条件,尽可能使用SSD硬盘, 不错的CPU.

ElasticSearch —修改ES数据

- -
ElasticSearch能够以接近实时的速度提供数据操作和搜索功能. 在默认情况下,从索引/更新/删除数据到出现在搜索结果之间,你可能会感受到有1秒的延迟时间(刷新间隔). 这是与SQL等其他平台的一个重要区别,这些平台在完成事务之后,它们的数据立即可用. 先前,我们已经知道如何索引一个单个的文档.

es近实时搜索原理

- - 企业架构 - ITeye博客
 随着按段(per-segment)搜索的发展, 一个新的文档从索引到可被搜索的延迟显著降低了. 新文档在几分钟之内即可被检索,但这样还是不够快.  提交(Commiting)一个新的段到磁盘需要一个 . fsync 来确保段被物理性地写入磁盘,这样在断电的时候就不会丢失数据. 但是  fsync 操作代价很大; 如果每次索引一个文档都去执行一次的话会造成很大的性能问题.

请警惕 ES 的三大坑

- - InfoQ推荐
搜索引擎现在是用得越来越多了,比如 日志系统用到的 ELK 中的 E 就是 搜索引擎 Elasticsearch(简称 ES). 那对于搜索这种技术来说,最看重的是搜索的结果的准确性和搜索的响应时间. ES 的准确性可以通过 倒排索引算法来保证,那响应时间就需要磁盘或缓存来支持了,那么磁盘和缓存会带来哪些坑呢.

碾压ES和MongoDB,RedisJson横空出世!

- - DockOne.io
近期官网给出了 RedisJson(RedisSearch)的性能测试报告,可谓碾压其他 NoSQL. 下面是核心的报告内容,先上结论:. 对于隔离写入(isolated writes),RedisJSON 比 MongoDB 快 5.4 倍,比 ElasticSearch 快 200 倍以上. 对于隔离读取(isolated reads),RedisJSON 比 MongoDB 快 12.7 倍,比 ElasticSearch 快 500 倍以上.

MySQL InnoDB 與 PostgreSQL 的 Partial Index(es) 是不一樣的東西…

- - Gea-Suan Lin's BLOG
MySQL InnoDB 指的 Partial Index 是:. An index that represents only part of a column value, typically the first N characters (the prefix) of a long VARCHAR value..