zifuy 的个人笔记

滚动升级

滚动升级允许Elasticsearch群集一次升级一个节点，因此升级不会中断服务。一旦超过升级期限,在同一集群中运行多个版本的Elasticsearch是不支持的,因为无法将分片从已升级的节点复制到运行旧版本的节点。

滚动升级可以在次要版本之间执行。Elasticsearch 6.x支持Elasticsearch 5.6的滚动升级。从较早的5.x版本升级需要完整的群集重启。您必须重新索引以从5.x之前的版本升级

要升级的对象

ES版本 Elasticsearch-7.3.2 oss版

ES节点 三节点 10.10.0.17 10.10.0.27 10.10.0.23

升级到

Elasticsearch-7.6.0

升级注意事项

1、节点升级需要一个节点一个节点的去升级。确认 ES 的 jvm.options内存设置的大小

2、最少需要三节点才能滚动升级成功(两个节点升级的话，当主节点停止时集群无法正常运行)

3、升级一个节点前，部署准备好要升级的文件、目录、权限、用户。

4、升级一个节点前先禁用分片分配，节点加入后开启分片分配 ，观察集群状态，每个节点加入前后都要禁用、启用集群分片复制。

5、所有节点加入后并开启分片复制后，集群状态才会逐步恢复到 100%

6、当所有节点升级完成后kibana才能用升级后的kibana去连接ES。否则启动kibnan会提示es还是旧版本

7、升级过程中可借助Cerebro可视化工具查看、配置（主要是启用禁用分片复制和查看ES集群健康状态）

Cerebro 部署可参考本博客ELK分类部分相关文章

禁用分片分配复制

关闭节点时，分配过程会等待一分钟，然后才能将该节点上的分片复制到集群中的其他节点，从而导致大量浪费的I / O资源。在关闭节点之前，可以通过禁用分配来避免耗时的分片分配行为

命令

curl -X PUT "192.168.200.200:9200/_cluster/settings" -H 'Content-Type: application/json' -d'  
{  
 "persistent": {  
 "cluster.routing.allocation.enable": "none"  
 }  
}  
'  

提示 [cluster.routing.allocation.enable] from [all] to [none] 表示禁用成功

启用分片分配复制

待升级过的节点加入后启用分片复制

curl -X PUT "192.168.200.200:9200/_cluster/settings" -H 'Content-Type: application/json' -d'  
{  
 "persistent": {  
 "cluster.routing.allocation.enable": "all"  
 }  
}  
'  

需要事先借助的命令

查看集群索引

curl -XGET -u elastic:123456 "10.10.0.27:9200/_cat/indices"

查看集群健康状态

curl -XGET -u elastic:123456 "10.10.0.23:9200/_cat/health?v"

查看ES节点情况

curl -XGET -u elastic:123456 "10.10.0.17:9200/_cat/nodes?v"

查看license

curl -XGET -u elastic:123456 http://10.10.2.17:9200/_license

集群健康命令详解

cluster ，集群名称
status，集群状态 green代表健康；yellow代表分配了所有主分片，但至少缺少一个副本，此时集群数据仍旧完整；red代表部分主分片不可用，可能已经丢失数据。
node.total，代表在线的节点总数量
node.data，代表在线的数据节点的数量
shards， active_shards 存活的分片数量
pri，active_primary_shards 存活的主分片数量 正常情况下 shards的数量是pri的两倍。
relo， relocating_shards 迁移中的分片数量，正常情况为 0
init， initializing_shards 初始化中的分片数量 正常情况为 0
unassign， unassigned_shards 未分配的分片 正常情况为 0
pending_tasks，准备中的任务，任务指迁移分片等 正常情况为 0
max_task_wait_time，任务最长等待时间
active_shards_percent，正常分片百分比 正常情况为 100%

升级步骤

升级第一个节点 10.10.0.27

1、准备 elasticsearch-7.6.0-linux-x86_64.tar.gz 文件 解压 进入 config 目录修改配置文件为如下

cluster.name: xd-tsp-log-es
node.name: ${HOSTNAME}
path.data: /data/elk7.6
path.logs: /var/log/elk
network.host: 10.10.0.27
http.port: 9200
discovery.seed_hosts: ["10.10.0.27", "10.10.0.17","10.10.0.23"]
cluster.initial_master_nodes: ["10.10.0.27","10.10.0.17","10.10.0.23"]
xpack.security.enabled: true
xpack.security.transport.ssl.enabled: true
xpack.security.transport.ssl.verification_mode: certificate
xpack.security.transport.ssl.keystore.path: elastic-certificates.p12
xpack.security.transport.ssl.truststore.path: elastic-certificates.p12

上面的目录可以按情况修改。注意权限

创建 elk用户 并赋予 新部署的es文件 elk用户权限

useradd elk 

chown -R elk.elk /data/elk7.6

chown -R elk.elk /var/log/elk

2、将原ES的 elastic-certificates.p12 文件拷贝至 新部署的ES config/ 目录下并授权

chown -R elk.elk /usr/local/ elasticsearch-7.6.0/config/elastic-certificates.p12

3、停用集群分片复制功能

curl -X PUT -u elastic:123456 "10.10.0.17:9200/_cluster/settings" -H 'Content-Type: application/json' -d'  
{  
 "persistent": {  
 "cluster.routing.allocation.enable": "none"  
 }  
}  
'  

4、停止 10.10.0.27节点上的ES

systemctl stop elasticsearch

查看健康状态

此时可用性60%

动态调整新节点分片复制速度

使用如下命令

curl -X PUT -u elastic:123456 "10.10.0.2:9200/_cluster/settings" -H 'Content-Type: application/json' -d'  
{  
 "persistent": {  
 "cluster.routing.allocation.node_concurrent_recoveries": 64  
 }  
}  

注意，64 数值越大对主机内存及jvm设置的内存要求越高。上面是 8 core
31 G内存下设置的参数。

5、启动新部署的ES，并查看日志内容

su elk

nohup /usr/local/elasticsearch-7.6.0/bin/elasticsearch > /dev/null &

tail -100f /var/log/elk/xd-tsp-log-es.log

6、查看新启动的ES是否加入了集群

curl -XGET -u elastic:123456 "10.10.0.27:9200/_cat/nodes?v"

curl -XGET -u elastic:123456 "10.10.0.27:9200/_cat/health?v"

此时新部署的系节点成功加入集群，但是 可用性为60% ，unassign 为 4。unassign(未分配的分片 正常情况为 0) 这里并不是 0 ,active_shards_percent也不是 100%，因为分片复制没有打开。不能往新节点复制分片

7、开启集群分片复制功能

curl -X PUT -u elastic:123456 "10.10.0.17:9200/_cluster/settings" -H 'Content-Type: application/json' -d'  
{  
 "persistent": {  
 "cluster.routing.allocation.enable": "all"  
 }  
}  
'  

再次查看集群健康状态

curl -XGET -u elastic:123456 "10.10.0.17:9200/_cat/health?v"

此时数据可用性达到100%，init为0.

注意：

此时 unassign(未分配的分片 正常情况为 0) 这里并不是 0 ,active_shards_percent也不是 100%，因为新加入的节点版本比其他两个旧的版本都要高，且新版本节点只有一个，所以 unassign 这里无法往其他节点复制，待第二个新版本节点加入后，unassign这里会变成 0。active_shards_percent 逐步达到 100%

bt-detection-h5-prod-2020.03.22                        0 p STARTED             1    8.8kb 10.20.11.16 xd-tsp-log-es-02
bt-detection-h5-prod-2020.03.22                        0 r UNASSIGNED    

如上是升级的第一个新版本节点上生成了索引，集群分片副本策略是1分片、1副本。但是无法往其他节点复制副本（因为新加入的节点版本比其他两个旧的版本都要高），变成了unassign 状态。导致集群升级到最后99.9% 不是健康状态

解决，将这个unassign 状态的索引副本数量设置为0 即可。

设置方法：可以使用 cerebro

剩余两个节点重复上面 1-7 步的过程即可。

当所有节点升级完成后kibana才能用升级后的kibana去连接ES。否则启动kibnan会提示es还是旧版本。

报错处理

1、最后有个节点如果新的部署后启动提示如下错误

Authentication of [elastic] was terminated by realm [reserved] - failed to authenticate user [elastic]

解决

重新生成集群密码即可，无需重启

2、升级一段时间后报错如下

Data too large, data for [<transport_request>] would be [986868914/941.1mb], which is larger than the limit of 

解决

参考，主要是jvm内存不足导致

修改 jvm.options

-Xms16g
-Xmx16g

根据自己主机内存状态进行调整重启ES节点即可