Elasticsearch1.7到2.3升级实践总结
2016-10-11 16:43
162 查看
概括
简述
升级分为Elasticsearch server升级和Elasticsearch client api升级为什么要迁移
当前团队内多个业务方公用一套ES集群,容易被影响,重要业务应该独自搭建一套集群迁移的优势:
降低业务耦合性,加强不同业务隔离;
丰富的资源提供更好的服务支撑;
为什么选择ES2.3
在1.X系列之上,ES2.X算是开启了又一个重要的里程碑,文档的展示样式也体现了该版本的重要性,当然了这只是冰山一角;下边是增强说明(下边两幅图说明了同一个观点:更优秀的功能集成在了2.X版本上):
附上地址:https://www.elastic.co/blog/release-we-have 新功能
我们既然决定了迁移,那就一起升级到优秀的版本,2.3.3是当时最新的版本,算是比较稳定的版本,看他最近一次提交是5.17;
迁移的效果如何
上边两个接口的迁移效果
因为上周中间才开始,还在观察期,中间的几个突兀是期间来回切换重启,缓存失效引起,当然,这个效果是ES Server在基本上没怎么调优的情况下的效果,之后会一遍观察,一遍调优,找出适合我们自己的配置;
ES升级方案
升级策略
搭建自己业务独立的ES集群(2.3.3)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.html2.0比1.7的变化
其中红色部分是这次迁移过程中遇到需要解决的问题,带箭头的是ES Server变化的相关部分,不带箭头的是代码层面需要变化的部分;
其中,代码改动部分最大的是Query DSL changes;
2.1的变化
search changes:search type的count和scan过期了;
2.2的变化
2.3的变化
比较少,摘一个如何同步迁移时的新需求
从master分支上上新开一个branch ,每次master增加新功能,上线之后,立马同步到新的branch,时时保证同步性;迁移流程
搭建一套新的ES2.3.3集群;全量写入数据索引,观察ES写入是否正常,修改出现的问题,直至索引写入OK;
上线每天全量刷数据到索引的服务,观察两天,索引创建过程及结果正常;
此时线上有一套1.7的刷索引服务和读索引服务,还有一套ES2.3刷索引服务,此时ES2.3增量索引也正常进行;
将搭建好的ES2.3备份集群上线,收集数据服务接入该备份集群,通过双写的方式保证数据正常;
在3、4、5进行期间,在测试环境上部署ES2.3的搜索服务,通过这段时间线下的点击来发现问题,修复直至搜索和1.7结果一致;
原有服务4台Server,增加一台Server,发ES2.3API端的分支(该分支请求ES2.3索引),通过流量配置平台将该台server流量调至1/50,通过观察错误日志和监控图表,直至无问题;(此时有问题,通过OCTO的禁用,可以瞬间恢复)
继续放开流量,一边放流量一遍观察日志和监控,直到1/5,没问题,然后发新加的3台机器,直至放入1/2流量,继续观察,无问题后,通过服务管理平台禁用原来ES1.7的API端而不是直接下掉服务(这样即使有问题,可以通过服务管理平台的禁用瞬间恢复);PS:这个观察的时间还是蛮长的,几个小时吧
观察一段时间没什么问题,随后增加少量代码,实现一键切换的功能,验证、上线,完全上线之后,一键切换到备份集群,没什么问题,再切回来;
观察整个周末线上服务的一个运行情况,基本无大碍(有一个GC的问题,已经整理到需要解决的问题里边),然后将数据收集服务里边的一些定时任务迁移到ES2.3的收集服务里边,上线;
截止到上周末为止,升级、迁移基本完成,原有集群任务还在跑,考虑再跑这周,下周跑几天,没有问题的话,做一下善后处理,下掉对ES1.7的完全引用,收拾收拾代码,开始ES2.3的业务之旅;
ES集群宕机方案
索引
采用双写的机制,保证当前使用索引和备份索引保持一致;搜索
采用ZK配置,一键切换使用集群;相关文章推荐
- GlusterFS的升级总结与实践
- Asp.net1.0 升级 ASP.NET 2.0 的几个问题总结 (转)
- 使用Web Services 来实现软件自动升级的实践
- Asp.net1.0 升级 ASP.NET 2.0 的几个问题总结
- Asp.net1.0 升级 ASP.NET 2.0 的几个问题总结
- Asp.net 1.0 升级至 ASP.NET 2.0十个问题总结
- Asp.net 1.0 升级至 ASP.NET 2.0十个问题总结
- Asp.net 1.0 升级至 ASP.NET 2.0十个问题总结(转)
- Asp.net 1.1 升级至ASP.NET 2.0 十个问题总结
- Asp.net1.0 升级 ASP.NET 2.0 的几个问题总结(转)
- 阅读《Programming Pearls second Edition》后的一些总结和个人实践的套用
- ASP.NET1.0升级ASP.NET2.0的问题总结
- Asp.net1.0 升级 ASP.NET 2.0 的几个问题总结
- 理论为实践服务:ASP开发10条经验总结
- Asp.net1.0 升级 ASP.NET 2.0 的几个问题总结
- 用源码包安装php-4.34+mysql-4.0.16+apache-2.0.48+vbb-2.32实践总结
- redhat9内核升级实践(2.4.20-8到2.4.26)
- Asp.net1.0 升级 ASP.NET 2.0 的几个问题总结
- Asp.net 1.0 升级至 ASP.NET 2.0十个问题总结
- Asp.net 1.0 升级至 ASP.NET 2.0十个问题总结