唐瀚林 2024-02-27 10:30 采纳率: 0%
浏览 105

elasticsearch分片异常,如何解决?

ElasticSearch中有一个索引中的编号2的主分片是UNASSIGNED这个状态,导致在查询ES时出现了

[2024-02-26T16:36:22,586][WARN ][r.suppressed             ] [4-PTU3i] path: /monitor_index_log/fullLog/d4d766f4ef4742909265655a04e56***, params: {index=monitor_index_log, id=d4d766f4ef4742909265655a04e56***, type=fullLog, timeout=1m}
org.elasticsearch.action.UnavailableShardsException: [monitor_index_log][2] primary shard is not active Timeout: [1m], request: [BulkShardRequest [[monitor_index_log][2]] containing [index {[monitor_index_log][fullLog][d4d766f4ef4742909265655a04e56***], source[n/a, actual length: [4.4kb], max length: 2kb]}]]
    at org.elasticsearch.action.support.replication.TransportReplicationAction$ReroutePhase.retryBecauseUnavailable(TransportReplicationAction.java:977) [elasticsearch-6.6.1.jar:6.6.1]
    at org.elasticsearch.action.support.replication.TransportReplicationAction$ReroutePhase.retryIfUnavailable(TransportReplicationAction.java:854) [elasticsearch-6.6.1.jar:6.6.1]
    at org.elasticsearch.action.support.replication.TransportReplicationAction$ReroutePhase.doRun(TransportReplicationAction.java:806) [elasticsearch-6.6.1.jar:6.6.1]

这是monitor_index_log索引的分片情况:

monitor_index_log  1 p STARTED    9627641  40.6gb *0.21*.*.** 4-PTU3i
monitor_index_log  1 r UNASSIGNED                              
monitor_index_log  2 p UNASSIGNED                              
monitor_index_log  2 r UNASSIGNED                              
monitor_index_log  4 p STARTED    9625519  40.6gb *0.21*.*.** 4-PTU3i
monitor_index_log  4 r UNASSIGNED                              
monitor_index_log  3 p STARTED    9626054  40.8gb *0.21*.*.** 4-PTU3i
monitor_index_log  3 r UNASSIGNED                              
monitor_index_log  0 p STARTED    9625479  40.7gb *0.21*.*.** 4-PTU3i
monitor_index_log  0 r UNASSIGNED 

我尝试将分片分配到4-PTU3i节点上出现了monitor_index_log 索引的第 2 个分片是主分片,并且处于未分配状态。失败的分配原因是 ALLOCATION_FAILED,节点上的分片无法正常恢复

{"index":"monitor_index_log","shard":2,"primary":true,"current_state":"unassigned","unassigned_info":{"reason":"CLUSTER_RECOVERED","at":"2024-02-26T09:35:43.528Z","last_allocation_status":"no_valid_shard_copy"},"can_allocate":"no_valid_shard_copy","allocate_explanation":"cannot allocate because all found copies of the shard are either stale or corrupt","node_allocation_decisions":[{"node_id":"4-PTU3i1SyewNc3ze3Igxg","node_name":"4-PTU3i","transport_address":"10.21*.*.**:9300","node_attributes":{"ml.machine_memory":"33817477120","xpack.installed":"true","ml.max_open_jobs":"20","ml.enabled":"true"},"node_decision":"no","store":{"in_sync":false,"allocation_id":"lPtyO0KDQOSHXAS-aDQ2uw"}}]}

ES是单节点,想请问一下出现这种问题该如何解决

  • 写回答

4条回答 默认 最新

  • 专家-赤兔[在线] 优质创作者: 编程框架技术领域 2024-02-27 10:32
    关注

    引自免费微信小程序:皆我百晓生

    在Elasticsearch中,分片未分配(UNASSIGNED)通常表示集群在尝试为该分片找到一个合适的节点进行分配时遇到了问题。针对你描述的情况,主分片2和其对应的副本分片均处于未分配状态,并且分配失败的原因是ALLOCATION_FAILED,具体原因为no_valid_shard_copy,这意味着集群无法找到有效的分片副本进行分配。

    解决这个问题需要排查以下几个方面:

    1. 数据丢失或损坏

      • 确认数据节点上是否有该分片的有效副本。如果有,可能是元数据错误导致的无法识别有效副本。可以通过查看相关节点的数据目录下是否存在对应分片的文件来判断。
      • 如果确实存在数据丢失或损坏,可能需要从备份恢复数据,或者如果数据可以容忍丢失,则删除索引并重新创建。
    2. 磁盘空间不足

      • 检查目标节点(如4-PTU3i)的磁盘空间是否足够。若磁盘空间不足,ES将无法分配新的分片。
    3. 分片设置与节点属性匹配问题

      • 检查节点的属性设置(如 node.attr.*),确保没有不兼容的限制性属性阻止了分片在这个节点上分配。
    4. 集群健康检查

      • 运行集群健康检查命令,确认集群整体状况:
        curl -X GET "localhost:9200/_cluster/health?pretty"
        
    5. 手动强制分配分片

      • 在某些情况下,你可以尝试手动强制分配分片,但这并不总是推荐的解决方案,因为它可能会覆盖集群自动平衡的决策。仅当确定节点能够承载该分片时才执行此操作:
        curl -X POST "localhost:9200/_cluster/reroute" -H 'Content-Type: application/json' -d'
        {
          "commands": [
            {
              "allocate_stale_primary": {
                "index": "monitor_index_log",
                "shard": 2,
                "node": "4-PTU3i", 
                "accept_data_loss": true
              }
            }
          ]
        }'
        

      注意:accept_data_loss 参数意味着即使数据可能存在损坏,也允许分配。只有在你知道这样做不会影响业务时才使用它。

    6. 清理无效分片

      • 如果由于旧的、无效的或损坏的分片副本导致问题,可以尝试清理这些无效数据,然后让集群重新分配分片。这通常涉及停服维护和直接操作数据目录的内容,非常谨慎操作。
    7. 检查集群日志

      • 查看Elasticsearch的日志以获取更具体的错误信息,这有助于定位问题的具体原因。
    8. 升级或重启集群

      • 如果集群曾遇到过严重的网络中断或其他系统级问题,尝试重启整个集群或升级到最新稳定版,以修复潜在的软件问题。

    总结来说,处理这类问题首先应确保集群及节点的状态良好,有足够的资源,并检查日志了解详细的错误信息。根据具体情况,采取相应的措施解决问题,必要时可寻求专业支持或查阅官方文档以获取更多帮助。

    评论

报告相同问题?

问题事件

  • 修改了问题 2月27日
  • 创建了问题 2月27日