es恢复集群后报错

在恢复Elasticsearch集群时,由于配置错误导致所有节点的node.name相同,造成分片无法正确分配,集群状态变为red。解决办法包括将副本数设置为0以减少unassigned分片,手动reroute转移未分配的分片,并最终恢复副本数至正常。通过监控集群状态并调整分片分配,成功将集群恢复至green状态。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

1、说明

集群本来有三个节点,但是异常情况导致两个节点安装es的磁盘丢失了,之后恢复了磁盘,然后恢复集群,恢复集群我是把好的es的整个目录拷贝到刚恢复的节点上,然后修改配置文件。

 

好的节点的配置文件如下所示:

$ egrep -v "^#|^$" elasticsearch.yml

cluster.name: elasticsearch

node.name: "node 14.69"

bootstrap.mlockall: true

network.host: 192.168.14.69

discovery.zen.minimum_master_nodes: 1

discovery.zen.ping.timeout: 60s

discovery.zen.ping.multicast.enabled: false

discovery.zen.ping.unicast.hosts: ["192.168.14.40","192.168.14.177","192.168.14.69"]

 

拷贝后修改刚恢复的两个节点的配置文件,但是由于疏忽,忘记修改node.name这个参数,所以在集群起来后所有节点的node.name都是node 14.69,之后又新的数据进来后,就出现了 unassigned 的分片,在head插件的页面上就会在最上面出现一行 unassigned 的分片,集群的状态也变为red。

 

上面的情况是怎么出现的?下面分析下:

新建索引,默认是5个分片,1个副本,副本分片的主要目的就是为了故障转移,如果持有主分片的节点挂掉了,一个副本分片就会晋升为主分片的角色。

 

副本分片和主分片是不能放到一个节点上面的,当副本分片没有办法分配到其他的节点上,所以出现所有副本分片都unassigned得情况。因为配置失误,所以集群被识别为只有一个节点。

 

2、解决办法:

查看节点的状态

$ curl -XGET http://192.168.14.69:9200/_cluster/health\?pretty

{

  "cluster_name" : "elasticsearch",

  "status" : "red",

  "timed_out" : false,

  "number_of_nodes" : 3,

  "number_of_data_nodes" : 3,

  "active_primary_shards" : 56,

  "active_shards" : 112,

  "relocating_shards" : 0,

  "initializing_shards" : 0,

  "unassigned_shards" : 52,

  "delayed_unassigned_shards" : 0,

  "number_of_pending_tasks" : 0,

  "number_of_in_flight_fetch" : 0

}

 

可以看到集群状态时red,未赋值的分片数是52个。

 

首先设置副本数为0

$ curl -XPUT "http://192.168.14.69:9200/_settings" -d'        

{

  "number_of_replicas" : 0

}'

 

再次查看节点的状态

$ curl -XGET http://192.168.14.69:9200/_cluster/health\?pretty

{

  "cluster_name" : "elasticsearch",

  "status" : "red",

  "timed_out" : false,

  "number_of_nodes" : 3,

  "number_of_data_nodes" : 3,

  "active_primary_shards" : 56,

  "active_shards" : 56,

  "relocating_shards" :

### Elasticsearch 数据迁移后安全异常问题解决方案 当完成Elasticsearch的数据迁移后,如果遇到`security exception`或用户认证失败的问题,通常是因为目标环境中的安全配置未正确同步或者存在差异。以下是可能的原因分析以及对应的解决方法: #### 1. 安全插件配置不同步 在某些情况下,源和目标Elasticsearch集群启用了不同的安全插件(如X-Pack Security、Open Distro for Elasticsearch Security)。这可能导致迁移后的用户角色、密码或其他安全设置无法正常工作。 - **验证当前安全状态** 使用以下命令检查目标节点上的安全功能是否启用: ```bash curl -X GET "localhost:9200/_cluster/settings?pretty" ``` 如果发现`xpack.security.enabled`被禁用,则需要重新启用它并加载相应的用户数据[^1]。 - **同步用户信息** 将源系统的`.security`索引迁移到新环境中可以保留原有的用户名和密码哈希值。可以通过`elasticdump`工具实现这一操作: ```bash elasticdump --input=http://source-es-node:9200/.security --output=http://target-es-node:9200/.security --type=data ``` #### 2. 权限不足引发错误 即使完成了基本的数据迁移,在访问控制层面仍可能存在权限缺失的情况。例如,尝试读取特定资源时抛出拒绝访问的异常。 - **调整文件夹所有权与权限** 对于存储路径下的所有子目录及其内容赋予适当的操作许可是非常重要的一步。具体做法如下所示: ```bash chown -R elasticsearch:elasticsearch /path/to/data/ chmod -R g+rwx /path/to/data/ find /path/to/data/ -type d -exec chmod 750 {} \; find /path/to/data/ -type f -exec chmod 640 {} \; ``` 上述脚本确保只有运行进程所属组能够完全操控这些资料,并对外界隐藏敏感细节。 #### 3. 配置文件冲突 有时由于版本升级或者其他原因导致的目标端`elasticsearch.yml`内的条目同实际需求不符也会引起类似的麻烦事态发生。 - **审查关键选项设定** 特别关注以下几个方面是否存在偏差: - `network.host`: 是否允许远程连接? - `discovery.seed_hosts`, `cluster.initial_master_nodes`: 列表里包含了哪些成员地址? - SSL/TLS证书关联项:客户端通信加密材料有无遗漏? 一旦发现问题所在之后便能着手修正它们直至恢复正常运作为止[^4]。 --- ```python # 示例Python代码用于测试连通性和身份验证状况 from elasticsearch import Elasticsearch, RequestsHttpConnection es_client = Elasticsearch( ['https://your-target-elasticsearch-host'], http_auth=('elastic', 'password'), # 替换真实凭据 connection_class=RequestsHttpConnection, use_ssl=True, verify_certs=False ) if es_client.ping(): print("Connected to ES cluster!") else: print("Could not connect.") ``` --- ###
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值