• Elasticsearch常见用法-分布式集群


    集群内部工作方式
    Elasticsearch用于构建高可用和可扩展的系统。扩展的方式可以是购买更好的服务器(纵向扩展(vertical scale or scaling up))或者购买更多的服务器(横向扩展(horizontal scale or scaling out))。
    Elasticsearch虽然能从更强大的硬件中获得更好的性能,但是纵向扩展有它的局限性。真正的扩展应该是横向的,它通过增加节点来均摊负载和增加可靠性。

    1. 空集群
      一个节点(node)就是一个Elasticsearch实例,而一个集群(cluster)由一个或多个节点组成,它们具有相同的 cluster.name ,它们协同工作,分享数据和负载。当加入新的节点或者删除一个节点时,集群就会感知到并平衡数据。
      集群中一个节点会被选举为主节点(master),它将临时管理集群级别的一些变更,例如新建或删除索引、增加或移除节点等。主节点不参与文档级别的变更或搜索,这意味着在流量增长的时候,该主节点不会成为集群的瓶颈。任何节点都可以成为主节点。
      做为用户,我们能够与集群中的任何节点通信,包括主节点。每一个节点都知道文档存在于哪个节点上,它们可以转发请求到相应的节点上。我们访问的节点负责收集各节点返回的数据,最后一起返回给客户端。这一切都由Elasticsearch处理。

    2. 集群健康
      在Elasticsearch集群中可以监控统计很多信息,但是只有一个是最重要的:集群健康(cluster health)。集群健康有三种状态: green 、 yellow 或 red 。

    GET /_cluster/health
    
    {
      "cluster_name" : "my-application",
      "status" : "green",
      "timed_out" : false,
      "number_of_nodes" : 1,
      "number_of_data_nodes" : 1,
      "active_primary_shards" : 14,
      "active_shards" : 14,
      "relocating_shards" : 0,
      "initializing_shards" : 0,
      "unassigned_shards" : 0,
      "delayed_unassigned_shards" : 0,
      "number_of_pending_tasks" : 0,
      "number_of_in_flight_fetch" : 0,
      "task_max_waiting_in_queue_millis" : 0,
      "active_shards_percent_as_number" : 100.0
    }
    

    status 字段提供一个综合的指标来表示集群的的服务状况。三种颜色各自的含义:

    • green:所有主要分片和复制分片都可用
    • yellow:所有主要分片可用,但不是所有复制分片都可用
    • red:不是所有的主要分片都可用

    主要分片(primary shard)和复制分片(replica shard)

    1. 添加索引
      索引只是一个用来指向一个或多个分片(shards)的“逻辑命名空间(logical namespace)”.一个分片(shard)是一个最小级别“工作单元(worker unit)”,它只是保存了索引中所有数据的一部分。
      分片就是一个Lucene实例,并且它本身就是一个完整的搜索引擎。文档存储在分片中,并且在分片中被索引,但是我们的应用程序不会直接与它们通信,取而代之的是,直接与索引通信。

    分片是Elasticsearch在集群中分发数据的关键。把分片想象成数据的容器。文档存储在分片中,然后分片分配到你集群中的节点上。当你的集群扩容或缩小,Elasticsearch将会自动在你的节点间迁移分片,以使集群保持平衡。
    分片可以是主分片(primary shard)或者是复制分片(replica shard)。你索引中的每个文档属于一个单独的主分片,所以主分片的数量决定了索引最多能存储多少数据。

    理论上主分片能存储的数据大小是没有限制的,限制取决于你实际的使用情况。分片的最大容量完全取决于你的使用状况:硬件存储的大小、文档的大小和复杂度、如何索引和查询你的文档,以及你期望的响应时间。

    复制分片只是主分片的一个副本,它可以防止硬件故障导致的数据丢失,同时可以提供读请求。

    当索引创建完成的时候,主分片的数量就固定了,但是复制分片的数量可以随时调整。

    创建一个叫做 blogs 的索引。默认情况下,一个索引被分配5个主分片,但是为了演示的目的,只分配3个主分片和一个复制分片(每个主分片都有一个复制分片):

    PUT /blogs
    {
      "settings" : {
        "number_of_shards" : 3,
        "number_of_replicas" : 1
      }
    }
    
    # 返回结果
    {
      "acknowledged" : true,
      "shards_acknowledged" : true,
      "index" : "blogs"
    }
    

    查看集群状态

    GET /_cluster/health
    
    # 返回结果
    {
      "cluster_name" : "my-application",
      "status" : "yellow", # 集群的状态现在是  yellow
      "timed_out" : false,
      "number_of_nodes" : 1,
      "number_of_data_nodes" : 1,
      "active_primary_shards" : 17,
      "active_shards" : 17,
      "relocating_shards" : 0,
      "initializing_shards" : 0,
      "unassigned_shards" : 3, # 三个复制分片还没有被分配到节点上
      "delayed_unassigned_shards" : 0,
      "number_of_pending_tasks" : 0,
      "number_of_in_flight_fetch" : 0,
      "task_max_waiting_in_queue_millis" : 0,
      "active_shards_percent_as_number" : 85.0
    }
    
    

    集群的健康状态 yellow 表示所有的主分片(primary shards)启动并且正常运行了,集群已经可以正常处理任何请求,但是复制分片(replica shards)还没有全部可用。
    事实上所有的三个复制分片现在都是 unassigned 状态,它们还未被分配给节点。
    在同一个节点上保存相同的数据副本是没有必要的,如果这个节点故障了,那所有的数据副本也会丢失。

    1. 故障转移
      启动第二个节点(只要第二个节点与第一个节点有相同的 cluster.name),它就能自动发现并加入第一个节点所在的集群。
      如果没有,检查日志找出哪里出了问题。这可能是网络广播被禁用,或者防火墙阻止了节点通信,或者配置文件出错,端口冲突等

    第二个节点已经加入集群,三个复制分片(replica shards)也已经被分配了——分别对应三个主分片,这意味着在丢失任意一个节点的情况下依旧可以保证数据的完整性。
    文档的索引将首先被存储在主分片中,然后并发复制到对应的复制节点上。这可以确保我们的数据在主节点和复制节点上都可以被检索。
    cluster-health 现在的状态是 green ,这意味着所有的6个分片(三个主分片和三个复制分片)都已可用
    集群的状态是 green ,不仅是功能完备的,而且是高可用的。

    1. 横向扩展
      启动第三个节点,集群会重新组织自己。包含3个节点的集群——分片已经被重新分配以平衡负载
      Node3 包含了分别来自 Node 1 和 Node 2 的一个分片,这样每个节点就有两个分片,和之前相比少了一个,这意味着每个节点上的分片将获得更多的硬件资源(CPU、RAM、I/O)。
      分片本身就是一个完整的搜索引擎,它可以使用单一节点的所有资源。6个分片(3个主分片和三个复制分片),最多可以扩展到6个节点,每个节点上有一个分片,每个分片可以100%使用这个节点的资源。

    2. 继续扩展
      如果我们要扩展到6个以上的节点,要怎么做?
      主分片的数量在创建索引时已经确定。实际上,这个数量定义了能存储到索引里数据的最大数量(实际的数量取决于你的数据、硬件和应用场景)。
      然而,主分片或者复制分片都可以处理读请求——搜索或文档检索,所以数据的冗余越多,我们能处理的搜索吞吐量就越大。
      复制分片的数量可以在运行中的集群中动态地变更,这允许我们可以根据需求扩大或者缩小规模。

    # 动态修改索引的副本数
    PUT /blogs/_settings
    {
      "settings" : {
        "number_of_replicas" : 0
      }
    }
    
    1. 应对故障
      杀掉的节点是一个主节点。一个集群必须要有一个主节点才能使其功能正常,所以集群做的第一件事就是各节点选举了一个新的主节点: Node 2 。
      索引在丢失主分片时不能正常工作。如果此时我们检查集群健康,我们将看到状态 red :不是所有主分片都可用!

    新主节点做的第一件事是把这些在 Node 2 和 Node 3 上的复制分片升级为主分片,这时集群健康回到 yellow 状态。这个提升是瞬间完成的,就好像按了一下开关。
    为什么集群健康状态是 yellow 而不是 green ?我们有三个主分片,但是我们指定了每个主分片对应两个复制分片,当前却只有一个复制分片被分配,这就是集群状态无法达到 green 的原因

    如果我们重启 Node 1 ,集群将能够重新分配丢失的复制分片,如果 Node 1 依旧有旧分片的拷贝,它将会尝试再利用它们,它只会从主分片上复制在故障期间有数据变更的那一部分。

  • 相关阅读:
    swoole 安装方法 使用即时聊天
    git的介绍以及简单应用
    curl的应用
    linux下监听和同步代码配置
    mac skim 修改背景色
    php 编译安装的一个 configure 配置
    mac mysql error You must reset your password using ALTER USER statement before executing this statement.
    yii2 控制器里 action 大小写组合造成的路由问题
    warning : json_decode(): option JSON_BIGINT_AS_STRING not implemented in xxx
    redis 自启动脚本
  • 原文地址:https://www.cnblogs.com/sanduzxcvbnm/p/12002112.html
Copyright © 2020-2023  润新知