Elasticsearch脑裂问题详细分析以及解决方案

Elasticsearch脑裂问题详细分析以及解决方案

什么是脑裂问题

• 脑裂问题其实就是同一个集群的不同节点对于整个几位群的状态有不同的理解，导致操作错乱，类似于精神分裂

怎么发现集群产生脑裂问题吧

• Elasticsearch出现查询非常缓慢的情况
• 通过命令查看集群的状态
  • curl -XGET ‘http://localhost:9200/_cluster/health’
• 发现集群状态为red，且集群数量明显错误，再向不同的节点查询集群状态的时候，总体状态都是red，但是返回的集群数量却不太一样
• 正常情况下，访问每一个节点，对集群中的状态返回应该是一致的。不一致的信息表示集群中不同节点对master节点的选择出现了问题。导致集群不能正常工作

产生脑裂问题的原因

• 网络
  • 由于某些节点之间的网络通信出现问题，导致一些节点认为master节点已经挂了，所以有重新选举了新的master节点，从而导致集群信息混乱，可以检查Ganglia集群监控，来查看是否是网络原因
• 节点负载过大：由于master节点与data节点都是混在一起的，有可能master节点的负载过大，导致对应的es实例停止响应，这时一部分节点会一位master节点已经挂掉从而重新选举，导致多master节点运行。同时由于data节点上ES进程占用的内存较大，较大规模的内存回收操作也能造成ES进程失去响应。所以，这个原因的可能性应该是最大的。

如何解决脑裂问题

• 对于网络问题，只能进行网络修复，在重启集群

• 对于负载的问题

  • 一个直观的解决方案就是将master节点与data节点分离，准备几台机器加入集群中，这几台机器只能充当master节点，不可担任存储和搜索的角色

    • 配置信息

    • node.master: true
      node.data: false
      其他节点  只能充当data不能充当master
      node.master: false
      node.data: true
      
      

  • 还有两个参数的修改可以减少脑裂问题的出现

    • discovery.zen.ping_timeout（默认值是3秒）：默认情况下，一个节点会认为，如果master节点在3秒之内没有应答，那么这个节点就是死掉了，而增加这个值，会增加节点等待响应的时间，从一定程度上会减少误判。
    • discovery.zen.minimum_master_nodes（默认是1）：这个参数控制的是，一个节点需要看到的具有master节点资格的最小数量，然后才能在集群中做操作。官方的推荐值是(N/2)+1，其中N是具有master资格的节点的数量

  • 如果脑裂问题已经发生该如何解决

    • 当脑裂发生后，唯一的修复办法是解决这个问题并重启集群。 当elasticsearch集群启动时，会选出一个主节点（一般是启动的第一个节点被选为主）。由于索引的两份拷贝已经不一样了，elasticsearch会认为选出来的主保留的分片是“主拷贝”并将这份拷贝推送给集群中的其他节点。这很严重。让我们设想下你是用的是node客户端并且一个节点保留了索引中的正确数据。但如果是另外的一个节点先启动并被选为主，它会将一份过期的索引数据推送给另一个节点，覆盖它，导致丢失了有效数据。
    • 所以怎么从脑裂中恢复？第一个建议是给所有数据重新索引。第二，如果脑裂发生了，要十分小心的重启你的集群。停掉所有节点并决定哪一个节点第一个启动。 如果需要，单独启动每个节点并分析它保存的数据。如果不是有效的，关掉它，并删除它数据目录的内容（删前先做个备份）。如果你找到了你想要保存数据的节点，启动它并且检查日志确保它被选为主节点。这之后你可以安全的启动你集群里的其他节点了。