vlambda博客
学习文章列表

从 Elasticsearch 集群的角度来看，它是最重要的节点类型。它处理集群状态，更改它，管理加入和离开集群的节点，检查集群中其他节点的健康状况（通过运行 ping 请求），并管理分片重定位操作。如果 master 以某种方式与集群断开连接，其余节点 将相互选择一个新的 master。所有这些过程都是根据我们提供的配置值自动完成的。您通常希望主节点仅与其他 Elasticsearch 节点通信，使用 内部 Java 通信。为避免误击主节点，建议在配置中为它们关闭 HTTP 模块。

数据节点负责保存索引中的数据。数据节点是需要最多磁盘空间的节点，因为加载了数据索引请求并在本地拥有的数据上运行搜索。类似于主节点的数据节点可以禁用 HTTP 模块。

客户端节点在大多数情况下是没有任何数据且不是主节点的节点。客户端节点是与外部世界和集群中所有节点通信的节点。他们将数据转发到适当的分片并聚合来自所有其他节点的搜索和聚合结果。

请记住， 客户端节点也可以拥有数据，但在这种情况下，它们 a> 将运行本地数据的索引请求和搜索请求，并将聚合来自其他节点的数据，这在大型集群中可能对单个节点来说工作量太大。

默认情况下，Elasticsearch 允许每个节点成为主节点、数据节点或客户端节点。但是，正如我们已经提到的，在某些情况下，您可能希望拥有仅保存数据的节点、仅用于处理请求的客户端节点以及用于 管理集群。一种这样的情况是当需要处理大量数据时，数据节点应该尽可能地高性能。为了告诉 Elasticsearch 它应该扮演什么角色，我们使用 elasticsearch.yml 配置文件中设置的三个布尔属性：

因此，要将节点设置为 只保存数据，我们应该将以下属性添加到 elasticsearch.yml 配置文件：

node.master: false
node.data: true
node.client: false

要将节点设置为不保存数据而仅作为主节点，我们需要指示 Elasticsearch 我们不希望节点保存数据。为此，我们将以下属性添加到 elasticsearch.yml 配置文件中：

node.master: true
node.data: false
node.client: false

假设您有一个由 10 个节点构建的集群。一切正常，直到有一天您的网络出现故障并且您的 3 个节点与集群断开连接，但它们仍然可以看到彼此。由于 Zen 发现和主节点选举过程，断开 的节点会选举一个新的主节点，您最终会得到两个同名的集群，其中两个主节点。这种情况称为脑裂，您必须尽可能避免这种情况。当发生脑裂时，您最终会得到两个（或更多）集群，这些集群在网络（或任何其他）问题得到解决之前不会相互连接。要记住的是，脑裂可能会导致不可恢复的错误，例如数据冲突，最终导致数据损坏或部分数据丢失。这就是为什么不惜一切代价避免这种情况很重要的原因。

为了防止出现脑裂情况，Elasticsearch 提供了一个 discovery.zen.minimum_master_nodes 属性。此属性定义了应相互连接以形成集群的主合格节点的最小数量。现在让我们回到我们的集群；如果我们将 discovery.zen.minimum_master_nodes 属性设置为可用节点总数的 50% + 1（在我们的例子中为 6），我们最终将得到一个集群。这是为什么？在网络故障之前，我们有10个节点，也就是6个以上的节点，这些节点组成了一个集群。在三个节点断开连接后，我们仍然可以让第一个集群启动并运行。但是，由于只有三个节点断开连接，并且三个小于六个，这三个节点将无法选举新的主节点，它们将等待与原始集群重新连接。

当然，这也不是一个完美的场景。建议只有一个专用的主合格节点，它们不能用作数据或客户端节点。在这种情况下，要获得法定人数，我们至少需要三个符合条件的专用主节点，因为这将允许我们让一个主节点离线并仍然保持法定人数。这通常足以使集群在掌握相关功能和防裂脑时保持良好状态。当然，在这种情况下， discovery.zen.minimum_master_nodes 属性应该设置为 2 我们应该有这三个主节点启动并运行。

此外，Elasticsearch 允许我们额外指定两个额外的布尔属性：discover.zen.master_election.filter_client 和 discover.zen.master_election.filter_data 。它们允许我们告诉 Elasticsearch 在主选举期间忽略来自客户端和数据节点的 ping 请求。默认情况下，第一个属性设置为 true，第二个属性设置为 false。这允许 Elasticsearch 专注于主节点选举，而不会因来自不符合主节点资格的节点的 ping 请求而过载。

除了提到的属性之外，Elasticsearch 还允许配置与主选举过程相关的超时。 discovery.zen.ping_timeout，默认为3s（三秒），允许为慢速网络配置超时——值越高，失败的机会越小，但选举过程可能需要更长的时间。第二个属性称为 discover.zen.join_timeout 并指定加入 master 请求的超时时间.它默认为 discovery.zen.ping_timeout 属性的 20 倍。

由于单播工作的 方式，我们至少需要指定单播消息应该发送到的主机。为此，我们应该将 discovery.zen.ping.unicast.hosts 属性添加到我们的 elasticsearch.yml 配置文件中。基本上，我们应该在 discovery.zen.ping.unicast.hosts 属性中指定构成集群的所有主机（我们不必指定所有主机，只需需要提供足够的东西，以便我们确定一个可以工作）。例如，如果我们想要主机 192.168.2.1、192.168.2.2 和 192.168。 2.3 对于我们的主机，我们应该通过以下方式指定前面的属性：

discovery.zen.ping.unicast.hosts: 192.168.2.1:9300, 192.168.2.2:9300, 192.168.2.3:9300

还可以定义 Elasticsearch 可以使用的端口范围。例如，要说可以使用从 9300 到 9399 的端口，我们指定以下内容：

discovery.zen.ping.unicast.hosts: 192.168.2.1:[9300-9399], 192.168.2.2:[9300-9399], 192.168.2.3:[9300-9399]

请注意，主机用逗号分隔，我们已经指定了我们期望单播消息的端口。

除了前面讨论的设置，我们还可以控制或更改默认 ping 配置。 Ping 是节点之间发送的信号，用于检查它们是否正在运行和响应。主节点 ping 集群中的所有其他节点， 集群中的每个其他节点都 ping 主节点。可以设置以下属性：

如果您的网络遇到一些问题，或者您知道您的节点需要更多时间才能看到 ping 响应，您可以将前面的值调整为适合您的 部署。

正如我们已经讨论过的，主节点负责处理集群状态的变化，而 Elasticsearch 允许我们控制该过程。对于大多数用例，默认设置就足够了，但您可能会遇到需要更改设置的情况。

主节点一次处理一个集群状态命令。首先主节点将更改传播到其他节点，然后等待响应。直到有足够多的节点向主节点响应并确认后，才认为每个集群状态更改都已完成。需要响应的节点数量由我们已经知道的 discovery.zen.minimum_master_nodes, 指定。 Elasticsearch 节点等待节点响应的最长时间默认为 30s，由 discovery.zen.commit_timeout 指定财产。如果没有足够的节点响应主节点，则拒绝集群状态更改。

一旦有足够多的节点响应主发布消息，主节点上就会接受集群状态更改并更改集群状态。一旦完成，主节点会向所有节点发送一条消息，说明可以应用更改。此消息的超时再次设置为 30 秒，并使用 discovery.zen.publish_timeout 属性进行控制。

如果集群没有主节点，无论是什么原因，它都不能完全运行。默认情况下，我们无法更改元数据，集群范围的命令将不起作用，等等。 Elasticsearch allows us to configure the behavior of the nodes when the master node is not elected.为此，我们可以使用 discovery.zen.no_master_block 属性来设置 all 和 写。将此属性设置为 all 表示该节点上的所有操作都将被拒绝，即搜索操作、写相关操作以及集群范围的操作，如健康或映射检索。将此属性设置为 write 意味着只有写操作会被拒绝——这是 Elasticsearch 的默认行为。

首先是完全禁用 HTTP。这有助于确保主节点和数据节点一般不会接受任何 查询或来自用户的请求。要完全禁用 HTTP 传输，我们只需在 elasticsearch.ymlhttp.enabled 属性并将其设置为 false > 文件。

Elasticsearch 允许我们 定义它将监听 HTTP 请求的端口。这是通过使用 http.port 属性来完成的。默认为 9200-9300，这意味着 Elasticsearch 将从 9200 端口开始，如果端口不可用则增加（因此下一个实例将使用 9201 端口等）。还有 http.publish_port, 在防火墙后面运行 Elasticsearch 和 HTTP 端口不可直接访问时非常有用。它定义连接到 Elasticsearch 的客户端应该使用哪个端口，并默认为与 http.port 属性相同的值。

我们还可以定义 Elasticsearch 将绑定到的主机。要指定它，我们需要定义 http.host 属性。默认值为网络模块设置的值。如果需要，我们可以分别设置发布主机和使用http.publish_host和<代码类="literal">http.bind_host 属性。您通常不必指定这些属性，除非您的节点具有非标准主机名或多个名称，并且您希望 Elasticsearch 仅绑定到一个。

您可以在 https://www.elastic.co/guide/en/elasticsearch/reference/2.2/modules- http.html。

除了上述选项之外，Elasticsearch 还允许我们进行一定程度的额外控制。这些额外的 选项是：

在恢复过程中还有另外一个——索引恢复API。它使我们能够看到索引或索引恢复的过程。要使用它，我们只需要指定索引并使用 _recovery 端点。例如，要检查 library 索引的恢复过程，我们将运行以下命令：

curl -XGET 'localhost:9200/library/_recovery?pretty'

前面命令的响应可能很大，并且取决于索引中的分片数量，当然还有我们想要获取信息的索引数量。在我们的例子中，响应如下所示（我们留下了有关单个分片的信息以使其不那么广泛）：

{
  "library" : {
    "shards" : [ {
      "id" : 0,
      "type" : "STORE",
      "stage" : "DONE",
      "primary" : true,
      "start_time_in_millis" : 1444030695956,
      "stop_time_in_millis" : 1444030695962,
      "total_time_in_millis" : 5,
      "source" : {
        "id" : "Brt5ejEVSVCkIfvY9iDMRQ",
        "host" : "127.0.0.1",
        "transport_address" : "127.0.0.1:9300",
        "ip" : "127.0.0.1",
        "name" : "Puff Adder"
      },
      "target" : {
        "id" : "Brt5ejEVSVCkIfvY9iDMRQ",
        "host" : "127.0.0.1",
        "transport_address" : "127.0.0.1:9300",
        "ip" : "127.0.0.1",
        "name" : "Puff Adder"
      },
      "index" : {
        "size" : {
          "total_in_bytes" : 157,
          "reused_in_bytes" : 157,
          "recovered_in_bytes" : 0,
          "percent" : "100.0%"
        },
        "files" : {
          "total" : 1,
          "reused" : 1,
          "recovered" : 0,
          "percent" : "100.0%"
        },
        "total_time_in_millis" : 1,
        "source_throttle_time_in_millis" : 0,
        "target_throttle_time_in_millis" : 0
      },
      "translog" : {
        "recovered" : 0,
        "total" : -1,
        "percent" : "-1.0%",
        "total_on_start" : -1,
        "total_time_in_millis" : 4
      },
      "verify_index" : {
        "check_index_time_in_millis" : 0,
        "total_time_in_millis" : 0
      }
    },
    ...
    ]
  }
}

正如您在响应中看到的，我们看到了有关每个分片的信息。对于每个分片，我们可以看到操作的类型（type 属性）、描述什么的阶段（stage 属性） 部分恢复过程正在进行中，以及是否是主分片（primary 属性） .除此之外，我们还会看到有关源分片、目标分片、分片所属索引、事务日志信息以及索引验证信息的部分。所有这些都让我们看到了我们的指数恢复的状态。

我们已经讨论过，默认情况下，Elasticsearch 会尝试根据集群中的节点数量来平衡集群中的分片。因此，当一个节点从 集群（或多个节点退出）或当节点加入集群时，Elasticsearch 开始重新平衡集群，移动分片和周围的复制品。这通常是非常昂贵的——新的主分片可能会从可用的副本中提升出来，大量的数据可能会在新的主分片和它的副本之间复制，等等。这可能是因为单个节点刚刚重新启动进行了 30 秒的维护。

为了避免这种情况，Elasticsearch 为我们提供了控制在开始分配处于未分配状态的分片之前等待多长时间的可能性。我们可以通过使用 index.unassigned.node_left.delayed_timeout 属性并根据每个索引设置它来控制延迟。例如，要将 library 索引的分配超时时间配置为 10 分钟，我们运行以下命令：

curl -XPUT 'localhost:9200/library/_settings' -d '{
 "settings": {
  "index.unassigned.node_left.delayed_timeout": "10m"
 }
}'

我们还可以通过运行以下命令为所有索引配置分配超时：

curl -XPUT 'localhost:9200/_all/_settings' -d '{
 "settings": {
  "index.unassigned.node_left.delayed_timeout": "10m"
 }
}'

在索引恢复过程中，Elasticsearch 2.2 公开了 一项新功能，允许我们定义在恢复时应优先考虑哪些索引。通过在索引设置中指定 index.priority 属性并为其分配一个正整数值，我们定义了 Elasticsearch 恢复索引的顺序； index.priority 属性较高的将首先启动。

例如，假设我们有两个索引，library 和 map， 我们想要 library 索引要在 map 索引之前恢复。为此，我们将运行以下命令：

curl -XPUT 'localhost:9200/library/_settings' -d '{
 "settings": {
  "index.priority": 10
 }
}'
curl -XPUT 'localhost:9200/map/_settings' -d '{
 "settings": {
  "index.priority": 1
 }
}'

我们为 library 索引分配了更高的优先级，因此，它将更快地恢复。

让我们看一个真实的 模板示例。想象一下，我们想要创建许多索引，我们不想在其中存储文档的来源，以便我们的索引更小。我们也不需要任何副本。我们可以使用 Elasticsearch REST API 和 /_template 端点创建符合我们需要的模板，方法是发送以下命令：

curl -XPUT http://localhost:9200/_template/main_template?pretty -d '{
  "template" : "*",
    "order" : 1,
    "settings" : {
    "index.number_of_replicas" : 0
  },
  "mappings" : {
    "_default_" : {
      "_source" : {
        "enabled" : false
      }
    }
  }
}'

从现在开始，所有创建的索引都没有副本，也没有存储源。这是因为模板参数值设置为 *，它匹配所有索引的名称。请注意我们示例中的 _default_ type 名称。这是一个特殊的类型名称，表示当前规则应该应用于每个文档类型。第二个有趣的事情是 order 参数。让我们使用以下命令定义第二个模板：

curl -XPUT http://localhost:9200/_template/ha_template?pretty -d '{
  "template" : "ha_*",
  "order" : 10,
  "settings" : {
    "index.number_of_replicas" : 5
  }
}'

运行前面的 命令后，除了名称以ha_。在这些索引的情况下，两个模板都被应用。首先，使用具有较低 order 值的模板，然后下一个模板覆盖副本的设置。因此，名称以 ha_ 开头的索引将存储五个副本和禁用的源。

我们有两种定义匹配模式的方法。它们如下：

默认情况下，该模式非常简单并使用 glob 模式。这可以通过使用 match_pattern=regexp 进行更改。添加此属性后，我们可以使用正则表达式提供的所有魔法来匹配和unmatch模式。 path_match 和 path_unmatch 等变体可用于匹配嵌套文档中的名称（通过提供路径，类似于查询）。

在编写 target 字段定义时，可以使用以下变量：

Elasticsearch 允许我们控制 fielddata 缓存使用多少内存。默认情况下，缓存是无界的，非常危险。如果您有大索引，您可能会遇到内存问题，其中 fielddata 缓存将占用 Elasticsearch 的大部分内存并导致节点故障。我们可以通过使用设置为显式值的静态 indices.fielddata.cache.size 属性（如 10GB）或分配给 Elasticsearch 的整个内存的百分比（如 20%）。

请记住，构建字段数据缓存非常昂贵，因为它需要将给定字段的所有值加载到内存中。这可能会花费大量时间，从而导致查询性能下降。因此，建议有足够的内存将所需的缓存永久保存在 Elasticsearch 内存中。但是，我们知道由于硬件成本，这并不总是可行的。

Elasticsearch 的好处是它允许我们以多种方式实现类似的事情， 在字段数据和限制内存方面我们也有同样的情况用法。 Elasticsearch 允许我们使用一个称为断路器的功能，它可以估计请求或查询将使用多少内存，如果超过定义的阈值，则根本不会执行，导致没有内存使用和抛出异常。当我们不想限制字段数据缓存的大小但我们也不希望单个查询导致内存问题并使集群不稳定时，这非常好。有两个主要的断路器：现场数据断路器和请求断路器。

第一个断路器，字段数据，估计将需要用于将数据加载到给定查询的 fielddata 缓存的内存量。我们可以使用 indices.breaker.fielddata.limit 属性来配置限制，默认设置为 60%，这意味着单个查询的字段数据缓存使用的内存不能超过 Elasticsearch 的 60%。

第二个断路器，请求一，估计每个请求数据结构使用的内存，并防止它们使用超过 indices.breaker.request.limit 属性指定的数量.默认情况下，上述属性设置为 40%，这意味着单个请求数据结构，例如用于聚合计算的数据结构，不能使用超过 40%分配给 Elasticsearch 的内存。

最后，还有一个由 indices.breaker.limit.total 属性定义的断路器（默认设置为 70% ）。这个断路器定义了每个请求数据结构和字段数据都可以使用的内存总量。

请记住，断路器的设置是动态的，可以使用集群更新设置进行更新。

分片请求 缓存默认是禁用的，但可以很容易地启用。要启用它，我们应该在 index.requests.cache.enable 属性设置为 true class="indexterm">创建索引。例如，要为名为 new_library， 的索引启用分片请求缓存，我们使用以下命令：

curl -XPUT 'localhost:9200/new_library' -d '{
 "settings": {
  "index.requests.cache.enable": true
 }
}'

要记住的一件事是，上述设置不可动态更新。我们需要将它包含在索引创建命令中，或者我们可以在索引关闭时更新它。

缓存的最大大小使用 indices.requests.cache.size 属性指定，默认设置为 1% （这意味着分配给 Elasticsearch 的总内存的 1%）。我们还可以使用 indices.requests.cache.expire 属性指定每个条目应保留多长时间，但默认情况下未设置。此外，一旦刷新索引（在索引搜索器重新打开期间），缓存就会失效，这< /a> 在大多数情况下使设置无用。

Elasticsearch 允许 我们控制基于每个请求使用的请求分片缓存。如果我们启用了上述缓存，我们仍然可以强制搜索引擎忽略此类请求的缓存。这是通过使用 request_cache 参数来完成的。如果设置为 true， 请求将被缓存，如果设置为 false， 请求将不会被缓存。当我们想要缓存我们的请求但忽略对一些罕见且不经常使用的查询的缓存时，这尤其有用。不缓存使用非确定性脚本和时间范围的请求也是明智之举。

如果我们不使用任何 监控软件来监控缓存使用情况，我们可以使用 Elasticsearch API 来检查分片请求缓存周围的指标。这可以在索引级别或节点级别完成。

要检查所有索引的分片请求缓存的指标，我们应该使用索引统计 API 并运行以下命令：

curl 'localhost:9200/_stats/request_cache?pretty'

要检查请求缓存指标，但在每个节点视图中，我们运行以下命令：

curl 'localhost:9200/_nodes/stats/indices/request_cache?pretty'