共计 4289 个字符，预计需要花费 11 分钟才能阅读完成。
概括
简述
升级分为 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 |
| node.name | 节点名称 |
|
√ | √ |
node |
|
node.master |
是否是 master |
|
√ | √ | |
|
node.data |
是否是 data |
|
√ | √ | |
|
index.number_of_shards |
索引分片数 |
|
√ | √ |
index
|
|
index.number_of_replicas |
索引备份数 |
|
√ | √ | |
|
index.refresh_interval |
refresh 时间 |
|
√ | √ | |
|
index.merge.scheduler.max_thread_count |
merge 线程数 |
|
√ | Χ | |
|
index.unassigned.node_left.delayed_timeout |
一个 node 脱离集群后多长时间之外才开始进行一系列的备份操作 |
|
√ | √ | |
|
index.search.slowlog.threshold.query.warn |
query 慢日志时间设置 |
|
√ | √ | |
|
index.search.slowlog.threshold.fetch.warn |
fetch 慢日志时间设置 |
|
√ | √ | |
|
index.indexing.slowlog.threshold.index.warn |
index 慢日志时间设置 |
|
√ | √ | |
|
monitor.jvm.gc.old.warn |
gc 时间设置 |
|
√ | √ |
monitor |
|
monitor.jvm.gc.old.info |
|
√ | √ | ||
|
monitor.jvm.gc.young.warn |
|
√ | √ | ||
|
monitor.jvm.gc.young.info |
|
√ | √ | ||
|
script.inline |
是否支持 script 表达式搜索 |
|
√ | Χ |
script |
|
script.indexed |
|
√ | Χ | ||
|
path.logs |
log 日志路径 |
|
√ | Χ |
path |
|
path.data |
存储数据路径 |
|
√ | Χ | |
|
network.host |
对外发布本机 ip |
|
Χ | Χ |
network |
|
transport.tcp.port |
通信端口 |
|
√ | Χ | |
|
http.port |
http 端口 |
|
√ | Χ | |
|
discovery.zen.ping.multicast.enabled |
是否开启相同集群名称则组成集群 |
|
Χ | Χ |
discovery |
|
discovery.zen.ping.unicast.hosts |
单播机器列表 |
|
√ | Χ | |
|
discovery.zen.minimum_master_nodes |
组成 master 集群的最小节点数 |
|
√ | Χ | |
|
gateway.recover_after_data_nodes |
full restart 参数设置 |
|
√ | Χ |
gateway |
|
gateway.expected_data_nodes |
|
√ | Χ | ||
|
gateway.expected_master_nodes |
|
√ | Χ | ||
|
gateway.recover_after_master_nodes |
|
√ | Χ | ||
|
gateway.expected_nodes |
|
√ | Χ | ||
|
gateway.recover_after_nodes |
|
√ | Χ | ||
|
gateway.recover_after_time |
|
√ | Χ | ||
|
action.disable_delete_all_indices |
是否允许全部删除 |
|
Χ | Χ |
action |
|
action.destructive_requires_name |
是否允许正则表达式删除 |
|
Χ | Χ | |
|
shield.enabled |
是否支持 shield |
|
Χ | Χ | 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，时时保证同步性；
迁移流程
- 搭建一套新的 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 配置，一键切换使用集群；
ElasticSearch 最新版本 2.20 发布下载了 http://www.linuxidc.com/Linux/2016-02/128166.htm
Linux 上安装部署 ElasticSearch 全程记录 http://www.linuxidc.com/Linux/2015-09/123241.htm
Elasticsearch 安装使用教程 http://www.linuxidc.com/Linux/2015-02/113615.htm
ElasticSearch 配置文件译文解析 http://www.linuxidc.com/Linux/2015-02/114244.htm
ElasticSearch 集群搭建实例 http://www.linuxidc.com/Linux/2015-02/114243.htm
分布式搜索 ElasticSearch 单机与服务器环境搭建 http://www.linuxidc.com/Linux/2012-05/60787.htm
ElasticSearch 的工作机制 http://www.linuxidc.com/Linux/2014-11/109922.htm
Elasticsearch 的安装，运行和基本配置 http://www.linuxidc.com/Linux/2016-07/133057.htm
使用 Elasticsearch + Logstash + Kibana 搭建日志集中分析平台实践 http://www.linuxidc.com/Linux/2015-12/126587.htm
Ubuntu 14.04 搭建 ELK 日志分析系统 (Elasticsearch+Logstash+Kibana) http://www.linuxidc.com/Linux/2016-06/132618.htm
ElasticSearch 的详细介绍 ：请点这里
ElasticSearch 的下载地址 ：请点这里
本文永久更新链接地址 ：http://www.linuxidc.com/Linux/2016-11/137282.htm
