• ElasticSearch 5学习(7)——分布式集群学习分享2


    前面主要学习了ElasticSearch分布式集群的存储过程中集群、节点和分片的知识(ElasticSearch 5学习(6)——分布式集群学习分享1),下面主要分享应对故障的一些实践。

    应对故障

    前面说了很多关于复制分片可以应对节点失效,很好保证集群的安全性,下面我们可以尝试杀掉第一个节点的进程,我们的集群变化成如下(所有的操作都是ElasticSearch自动处理):

    我们杀掉的节点是一个主节点。一个集群必须要有一个主节点才能使其功能正常,所以集群做的第一件事就是各节点选举了一个新的主节点:Node 2。

    主分片1和2在我们杀掉Node 1时已经丢失,我们的索引在丢失主分片时不能正常工作。如果此时我们检查集群健康,我们将看到状态red:不是所有主分片都可用!

    幸运的是丢失的两个主分片的完整拷贝存在于其他节点上,所以新主节点做的第一件事是把这些在Node 2和Node 3上的复制分片升级为主分片,这时集群健康回到yellow状态。这个提升是瞬间完成的,就好像按了一下开关。

    为什么集群健康状态是yellow而不是green?我们有三个主分片,但是我们指定了每个主分片对应两个复制分片,当前却只有一个复制分片被分配,这就是集群状态无法达到green的原因,不过不用太担心这个:当我们杀掉Node 2,我们的程序依然可以在没有丢失数据的情况下继续运行,因为Node 3还有每个分片的拷贝。

    如果我们重启Node 1,集群将能够重新分配丢失的复制分片,集群状况与上一节的 图5:增加number_of_replicas到2 类似。如果Node 1依旧有旧分片的拷贝,它将会尝试再利用它们,它只会从主分片上复制在故障期间有数据变更的那一部分。

    故障实践1

    上面是关于ElasticSearch在遇到故障时候的理论部分,下面我们开始实际操作。

    查看目前集群状态

    我们回顾一下之前的blogs索引,在结束最后的状态:

    PUT /blogs
    {
       "settings" : {
          "number_of_shards" : 3,    (主分片个数)
          "number_of_replicas" : 2,    (每个主分片的复制分片个数)
       }
    }
    

    切断节点

    为了模拟这种情况,在我们自己的电脑上,直接用kill命令即可:

    查看集群的状态

    很正确,就是理论内容所描述中间会存在red的瞬间。

    等·

    等·

    等·

    可是等了半天,结果一直是red状态的结果,这是为什么呢?注意看提示无法连接到http://localhost:9200,突然意识到,我们关闭的节点正好是9200端口的Node 1节点。所以我们需要修改kibana.yml配置文件的elasticsearch.url项:

    再次查看集群的状态

    终于,可以看到我们想要的结果,ElasticSearch集群正如上面所说的重新选Node 2作为新的主节点:

    我们还可以注意到集群的健康状况从绿色变成了黄色,这是因为我们设置每个主节点2个复制分片,而现在还有一个复制节点处于不可用状态。

    故障实践2

    回顾之前的一个集群状态,blogs索引只设置一个复制分片的情况下:

    如果在这种情况下,我们把其中的任何一个节点关闭,会出现什么效果呢?我们分析看,至少我们关闭任何一个节点都能保所有的分片都还能存在。比如我们删除Node 2节点,正常情况下,Node 2中的分片0作为主分片被删除后,主节点会分配Node 1节点下复制分片0重新作为主分片0,而Node 2中的分片1本身是复制分片,直接删除即可,但是ElasticSearch集群,除此之外还会不会有其他操作。那就是,从新在两个节点中把所有的复制分片都置为可用。下面我们看结果:

    首先我们看到的和我们前面分析的一样,主节点会分配Node 1节点下复制分片0重新作为主分片0,但是也可以看到现在集群的健康状况是黄色,因为存在复制节点处于不可用状态。我们继续等。。。:

    终于我们可以看到,ElasticSearch集群确实会把所有的复制节点又都置为可用状态,因为节点存在它不拥有的分片,就可以创建这个节点,最大程度的保证高可用性。

    实践注意点

    在测试过程中,ElasticSearch集群确实可以帮助我们重新分配分片的状态,但是需要注意的是,每次一个节点关闭的时候,集群需要一定的时间去管理,如果这时候我们很快的将两个节点关闭,ElasticSearch集群将无法挽救回没有主分片,也没有复制分片的那些数据,所以测试的时候需要知道这一点。

    不过这也反映我们在学习分享1中描述的,如果我们的复制节点足够多的话,我们可以保证高可用的能力就却强大,因为允许节点故障的次数更多,而且我们的节点故障以后,运维又可以将节点重启,继续斗争!!!

    总结

    现在我们对分片如何使Elasticsearch可以水平扩展并保证数据安全有了一个清晰的认识。真正感受到Elasticsearch天生就是分布式的,确实很强大!

    转载请注明出处。
    作者:wuxiwei
    出处:http://www.cnblogs.com/wxw16/p/6188560.html

  • 相关阅读:
    全面分析再动手的习惯:链表的反转问题(递归和非递归方式)
    Gatech OMSCS的申请和学习之奥妙
    java线程安全之并发Queue
    一篇文章看懂Java并发和线程安全
    java并发之如何解决线程安全问题
    Java并发/多线程系列——线程安全篇(1)
    当面试官问线程池时,你应该知道些什么?
    java 线程池 使用实例
    多线程-Executors和Executor,线程池
    从阿里Java开发手册学习线程池的正确创建方法
  • 原文地址:https://www.cnblogs.com/wxw16/p/6188560.html
Copyright © 2020-2023  润新知