Elasticsearch1.7到2.3升级实践总结

概括

简述

升级分为Elasticsearch server升级和Elasticsearch client api升级

为什么要迁移

当前团队内多个业务方公用一套ES集群，容易被影响，重要业务应该独自搭建一套集群

迁移的优势：

  1. 降低业务耦合性，加强不同业务隔离；
  2. 丰富的资源提供更好的服务支撑；

为什么选择ES2.3

在1.X系列之上，ES2.X算是开启了又一个重要的里程碑，文档的展示样式也体现了该版本的重要性，当然了这只是冰山一角；

下边是增强说明（下边两幅图说明了同一个观点：更优秀的功能集成在了2.X版本上）：

附上地址：https://www.elastic.co/blog/release-we-have   新功能

我们既然决定了迁移，那就一起升级到优秀的版本，2.3.3是当时最新的版本,算是比较稳定的版本，看他最近一次提交是5.17；

迁移的效果如何

    

上边两个接口的迁移效果

因为上周中间才开始，还在观察期，中间的几个突兀是期间来回切换重启，缓存失效引起，当然，这个效果是ES Server在基本上没怎么调优的情况下的效果，之后会一遍观察，一遍调优，找出适合我们自己的配置；

ES升级方案

升级策略

  1. 搭建自己业务独立的ES集群(2.3.3)
  2. API更新换代

配置文件

*以下列表中的参数可支持自动化配置，其余未列出来皆用默认配置（如有不妥，请及时纠偏，尤其是 配置节点类型一列）

配置参数功能简介配置节点类型自动化配置建议配置所属模块
cluster.name
 集群名称
  • data
  • master
 √ √ cluster
node.name 节点名称
  • data
  • master
 √ √

 

 

node

node.master

 是否是master
  • data
  • master
 √ √

node.data

 是否是data
  • data
  • master
 √ √

index.number_of_shards

 索引分片数
  • data
  • master
 √ √







 

index

 

index.number_of_replicas

 索引备份数
  • data
  • master
 √ √

index.refresh_interval

 refresh时间
  • data
  • master
 √ √

index.merge.scheduler.max_thread_count

 merge线程数
  • data
  • master
 √ Χ

index.unassigned.node_left.delayed_timeout

 一个node脱离集群后多长时间之外才开始进行一系列的备份操作
  • data
  • master
 √ √

index.search.slowlog.threshold.query.warn

 query慢日志时间设置
  • data
 √ √

index.search.slowlog.threshold.fetch.warn

 fetch慢日志时间设置
  • data
 √ √

index.indexing.slowlog.threshold.index.warn

 index慢日志时间设置
  • data
 √ √

monitor.jvm.gc.old.warn

 gc时间设置
  • data
  • master
 √ √




 

monitor

monitor.jvm.gc.old.info
  • data
  • master
 √ √

monitor.jvm.gc.young.warn
  • data
  • master
 √ √

monitor.jvm.gc.young.info
  • data
  • master
 √ √

script.inline

 是否支持script表达式搜索
  • data
 √ Χ

 

script

script.indexed
  • data
 √ Χ

path.logs

 log日志路径
  • data
  • master
 √ Χ

 

path

path.data

 存储数据路径
  • data
  • master
 √ Χ

network.host

 对外发布本机ip
  • data
  • master
 Χ Χ

 

 

network

transport.tcp.port

 通信端口
  • data
  • master
 √ Χ

http.port

 http端口
  • data
  • master
 √ Χ

discovery.zen.ping.multicast.enabled

 是否开启相同集群名称则组成集群
  • data
  • master
 Χ Χ

 

 

discovery

discovery.zen.ping.unicast.hosts

 单播机器列表
  • data
  • master
 √ Χ

discovery.zen.minimum_master_nodes

 组成master集群的最小节点数
  • master
 √ Χ

gateway.recover_after_data_nodes

 full restart 参数设置
  • data
 √ Χ

 

 

 

 

 

gateway

gateway.expected_data_nodes
  • data
 √ Χ

gateway.expected_master_nodes
  • master
 √ Χ

gateway.recover_after_master_nodes
  • master
 √ Χ

gateway.expected_nodes
  • data
  • master
 √ Χ

 gateway.recover_after_nodes
  • data
  • master
 √ Χ

gateway.recover_after_time
  • data
  • master
 √ Χ

action.disable_delete_all_indices

 是否允许全部删除
  • data
  • master
 Χ Χ

 

action

action.destructive_requires_name

 是否允许正则表达式删除
  • data
  • master
 Χ Χ

shield.enabled

 是否支持shield
  • data
  • master
 Χ Χ shield

插件

  • head

监控

监控方案：ElasticSearch集群监控报警指标梳理

监控效果：这部分为内部监控

异同

https://www.elastic.co/guide/en/elasticsearch/reference/current/breaking-changes-2.3.html

2.0比1.7的变化

其中红色部分是这次迁移过程中遇到需要解决的问题，带箭头的是ES Server变化的相关部分，不带箭头的是代码层面需要变化的部分；

其中，代码改动部分最大的是Query DSL changes;

2.1的变化

search changes：search type的count和scan过期了；

2.2的变化

2.3的变化

比较少，摘一个

如何同步迁移时的新需求

从master分支上上新开一个branch ，每次master增加新功能，上线之后，立马同步到新的branch，时时保证同步性；

迁移流程

  1. 搭建一套新的ES2.3.3集群；
  2. 全量写入数据索引，观察ES写入是否正常，修改出现的问题，直至索引写入OK；
  3. 上线每天全量刷数据到索引的服务，观察两天，索引创建过程及结果正常；
  4. 此时线上有一套1.7的刷索引服务和读索引服务，还有一套ES2.3刷索引服务，此时ES2.3增量索引也正常进行；
  5. 将搭建好的ES2.3备份集群上线，收集数据服务接入该备份集群，通过双写的方式保证数据正常；
  6. 在3、4、5进行期间，在测试环境上部署ES2.3的搜索服务，通过这段时间线下的点击来发现问题，修复直至搜索和1.7结果一致；
  7. 原有服务4台Server，增加一台Server，发ES2.3API端的分支（该分支请求ES2.3索引），通过流量配置平台将该台server流量调至1/50，通过观察错误日志和监控图表，直至无问题；（此时有问题，通过OCTO的禁用，可以瞬间恢复）
  8. 继续放开流量，一边放流量一遍观察日志和监控，直到1/5，没问题，然后发新加的3台机器，直至放入1/2流量，继续观察，无问题后，通过服务管理平台禁用原来ES1.7的API端而不是直接下掉服务（这样即使有问题，可以通过服务管理平台的禁用瞬间恢复）；PS：这个观察的时间还是蛮长的，几个小时吧
  9. 观察一段时间没什么问题，随后增加少量代码，实现一键切换的功能，验证、上线，完全上线之后，一键切换到备份集群，没什么问题，再切回来；
  10. 观察整个周末线上服务的一个运行情况，基本无大碍（有一个GC的问题，已经整理到需要解决的问题里边），然后将数据收集服务里边的一些定时任务迁移到ES2.3的收集服务里边，上线；
  11. 截止到上周末为止，升级、迁移基本完成，原有集群任务还在跑，考虑再跑这周，下周跑几天，没有问题的话，做一下善后处理，下掉对ES1.7的完全引用，收拾收拾代码，开始ES2.3的业务之旅；

ES集群宕机方案

索引

采用双写的机制，保证当前使用索引和备份索引保持一致；

搜索

采用ZK配置，一键切换使用集群；

posted @ 2016-10-11 16:43  凌渡冰  阅读(3353)  评论(2)  编辑  收藏  举报