集群版本升级——rolling upgrade在ES 单节点从 restart 到加入集群,大概要 100s 左右的时间。也就是说,这 100s 内,该节点上的所有分片都是 unassigned 状态-阿里云开发者社区

开发者社区> 桃子红了呐> 正文

集群版本升级——rolling upgrade在ES 单节点从 restart 到加入集群,大概要 100s 左右的时间。也就是说,这 100s 内,该节点上的所有分片都是 unassigned 状态

简介:
+关注继续查看

集群版本升级

Elasticsearch 作为一个新兴项目,版本更新非常快。而且每次版本更新都或多或少带有一些重要的性能优化、稳定性提升等特性。可以说,ES 集群的版本升级,是目前 ES 运维必然要做的一项工作。

按照 ES 官方设计,有 restart upgrade 和 rolling upgrade 两种可选的升级方式。对于 1.0 版本以上的用户,推荐采用 rolling upgreade 方式。

但是,对于主要负载是数据写入的 Elastic Stack 场景来说,却并不是这样!

rolling upgrade 的步骤大致如下:

  1. 暂停分片分配;
  2. 单节点下线升级重启;
  3. 开启分片分配;
  4. 等待集群状态变绿后继续上述步骤。

实际运行中,步骤 2 的 ES 单节点从 restart 到加入集群,大概要 100s 左右的时间。也就是说,这 100s 内,该节点上的所有分片都是 unassigned 状态。而按照 Elasticsearch 的设计,数据写入需要至少达到 replica/2+1 个分片完成才能算完成。也就意味着你所有索引都必须至少有 1 个以上副本分片开启。

但事实上,很多日志场景,由于写入性能上的要求要高于数据可靠性的要求,大家普遍减小了副本数量,甚至直接关掉副本复制。这样一来,整个 rolling upgrade 期间,数据写入就会受到严重影响,完全丧失了 rolling 的必要性。

其次,步骤 3 中的 ES 分片均衡过程中,由于 ES 的副本分片数据都需要从主分片走网络复制重新传输一次,而由于重启,新升级的节点上的分片肯定全是副本分片(除非压根没副本)。在数据量较大的情况下,这个步骤耗时可能是几十分钟甚至以小时计。而且并发和限速上稍微不注意,可能导致分片均衡的带宽直接占满网卡,正常写入也还是受到影响。

所以,对于写入压力较大,数据可靠性要求偏低的实时日志场景,依然建议大家进行主动停机式的 restart upgrade。

restart upgrade 的步骤如下:

  1. 首先适当加大集群的数据恢复和分片均衡并发度以及磁盘限速:
# curl -XPUT http://127.0.0.1:9200/_cluster/settings -d '{
  "persistent" : {
    "cluster" : {
      "routing" : {
        "allocation" : {
          "disable_allocation" : "false",
          "cluster_concurrent_rebalance" : "5",
          "node_concurrent_recoveries" : "5",
          "enable" : "all"
        }
      }
    },
    "indices" : {
      "recovery" : {
        "concurrent_streams" : "30",
        "max_bytes_per_sec" : "2gb"
      }
    }
  },
  "transient" : {
    "cluster" : {
      "routing" : {
        "allocation" : {
          "enable" : "all"
        }
      }
    }
  }
}'
  1. 暂停分片分配:
# curl -XPUT http://127.0.0.1:9200/_cluster/settings -d '{
  "transient" : {
    "cluster.routing.allocation.enable" : "none"
  }
}'
  1. 通过配置管理工具下发新版本软件包。
  2. 公告周知后,停止数据写入进程(即 logstash indexer 等)
  3. 如果使用 Elasticsearch 1.6 版本以上,可以手动运行一次 synced flush,同步副本分片的 commit id,缩小恢复时的网络传输带宽:
# curl -XPOST http://127.0.0.1:9200/_flush/synced
  1. 全集群统一停止进程,更新软件包,重新启动。
  2. 等待各节点都加入到集群以后,恢复分片分配:
# curl -XPUT http://127.0.0.1:9200/_cluster/settings -d '{
  "transient" : {
    "cluster.routing.allocation.enable" : "all"
  }
}'

由于同时启停,主分片几乎可以同时本地恢复,整个集群从 red 变成 yellow 只需要 2 分钟左右。而后的副本分片,如果有 synced flush,同样本地恢复,否则网络恢复总耗时,视数据大小而定,会明显大于单节点恢复的耗时。

  1. 如果有 synced flush,建议等待集群变成 green 状态后,恢复写入;否则在集群变成 yellow 状态之后,即可着手开始恢复数据写入进程。
















本文转自张昺华-sky博客园博客,原文链接:http://www.cnblogs.com/bonelee/p/7444394.html,如需转载请自行联系原作者

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
扩容阿里云kubernetes集群,并升级节点内核
作为早期阿里云 kubernetes 的产品经理, 控制台方式实现节点上下线是我提出来的需求。
687 0
Android managedQuery查询如果加入group by条件(及其猥琐的方法)
下午研究了很久都没有找到如何在managedQuery方法里面加入group by 条件最后灵机一动! 想出了一个及其猥琐的方法解决此问题! 此时我的需求是查出Calllog中的号码!相同的自然只出一个结果! 正常的查询是这样的! Cursor phoneCursor = this.
599 0
欢迎加入DataWorks产品钉钉交流群
欢迎加入DataWorks产品钉钉交流群,该群每日有值班针对dataworks问题进行讲解
22311 0
如何使用Terraform管理容器服务Kubernetes集群之-标准版集群
#### 介绍 Terraform 是一款 Infrastructure as Code 的工具,可以将云端资源代码化。关于 Terraform 的基本介绍本文不再赘述,有兴趣的同学可以参考 [《云生态下的基础架构资源管理利器Terraform》](https://yq.aliyun.com/articles/215592) 等云栖社区的优秀文章。
987 0
重磅|阿里云HBase Ganos全新升级,推空间、时空、遥感一体化基础云服务
Ganos是阿里云时空PaaS服务的自研核心引擎。Ganos已作为云数据库时空引擎与数据库平台融合,建立了以自研云原生数据库POALRDB为基础,联合NoSQL大数据平台(Ali-HBASE和X-Pack Spark)的完整时空地理信息云化管理解决方案。
2107 0
通过TAG将ECS实例(弹性扩缩容)自动加入云监控分组
基于阿里云弹性伸缩集成部署弹性服务ECS方案,同时基于云监控CMS利用标签实现ECS实例的自发现监控ECS实例,通过云监控CMS应用分组查看配置统一的监控告警服务、资源利用率、集中的报警管理,轻松实现ECS监控运维。也就是说,ECS+AutoScaling+TAG+CMS 实现自动化分组运维。
1062 0
嵌入式linux、QT、ARM、android研发学习交流,软考嵌入式系统设计师交流群,欢迎大家加入,群号95388240
 嵌入式linux、QT、ARM、android研发学习交流,软考嵌入式系统设计师交流群,欢迎大家加入,群号95388240
900 0
【51开放平台日志 2009年03月03日】51开放平台第三方小应用停机维护时间建议
【51开放平台日志 2009年03月03日】51开放平台第三方小应用停机维护时间建议 出自51.com developers wiki 跳转到: 导航, 搜索 通过我们的数据分析,51用户最少的时间段集中在:每天的凌晨4点~7点。
527 0
4269
文章
0
问答
文章排行榜
最热
最新
相关电子书
更多
《2021云上架构与运维峰会演讲合集》
立即下载
《零基础CSS入门教程》
立即下载
《零基础HTML入门教程》
立即下载