# 集群管理

# 节点分配

原集群 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