集群管理

节点分配

原集群 master*3 data*12 client*0

新集群 master*3 data*12 injest*0 coordinating*0

ingest 节点用于支持 pipeline 操作 对bulk和index文档进行预处理

coordinating 功能主要是分发请求,聚合各节点的处理结果,负载均衡,大规模集群可以设置一个给读,一个给写。但coordinating 数量也不宜过多,会拖慢选举主节点的时间,并且data节点其实也可以处理这些请求.

节点设置

search.remote.connect: false
node.ingest: false

数据迁移

数据源

由于有数据源及同步方案,所以只需数据全量导入6.3版本的集群即可.

索引管理

目前生产环境有300个索引需要同步,要检查同步脚本的创建索引,切别名等步骤.

mapping设置

  1. type 只支持1种,自 ES7.0 起将不再支持 type—官方说明
  2. 对可以使用自增 id 的索引使用自增 id
  3. 对大多数字符串字段使用 keyword 类型
  4. 对不用于数值范围查找的数值类型改为keyword类型
  5. 分词插件可能需要改动
  6. index: no 改为 index:false
  7. index: not_analyzed 删掉

提高迁移速度

  1. sudo swapoff -a
  2. 副本设置为0
  3. refresh_interval 设置为 -1 (对线上生产集群上索引批量导入时,设置-1后,重新打开时可能会导致集群压力暴增)
  4. 导入数据
  5. refresh_interval 设置为30
  6. 确认数据正确性
  7. POST /_forcemerge max_num_segments=1(对于大索引可能非常耗时)
  8. 副本设置为1

scala项目升级

  1. scala & play 升级, 尤其是play的升级会导致大量代码改动
  2. elastic4s 依赖升级,注意除了core包还需要http包 。
  3. 原本的获取client, 构建dsl,excute,解析response的大量代码要修改,尤其是构建dsl涉及大量业务,需要逐一比对修改。

监控

Prometheus + Grafana 主要是获取ES信息的api随之升级,改动通常不大

另外推荐 xpack 的 monitor,收集了 segment 的数据,收集了每个索引的请求量,响应时间等信息,信息集成进了 kibana