基础知识点

在Eleasticsearch中recovery指的就是一个索引的分片分配到另外一个节点的过程；一般在快照恢复、索引副本数变更、节点故障、节点重启时发生。由于master保存整个集群的状态信息，因此可以判断出哪些shard需要做再分配，以及分配到哪个结点，例如:

1. 如果某个shard主分片在，副分片所在结点挂了，那么选择另外一个可用结点，将副分片分配(allocate)上去，然后进行主从分片的复制；
2. 如果某个shard的主分片所在结点挂了，副分片还在，那么将副分片升级为主分片，然后做主从分片复制；
3. 如果某个shard的主副分片所在结点都挂了，则暂时无法恢复，等待持有相关数据的结点重新加入集群后，从该结点上恢复主分片，再选择另外的结点复制副分片。

正常情况下，我们可以通过ES的health的API接口，查看整个集群的健康状态和整个集群数据的完整性：

状态及含义如下：

• green: 所有的shard主副分片都是正常的；
• yellow: 所有shard的主分片都完好，部分副分片没有或者不完整，数据完整性依然完好；
• red: 某些shard的主副分片都没有了，对应的索引数据不完整。

ecovery过程要消耗额外的资源，CPU、内存、结点之间的网络带宽等等。 这些额外的资源消耗，有可能会导致集群的服务性能下降，或者一部分功能暂时不可用。了解一些recovery的过程和相关的配置参数，对于减小recovery带来的资源消耗，加快集群恢复过程都是很有帮助的。

减少集群Full Restart造成的数据来回拷贝

ES集群可能会有整体重启的情况，比如需要升级硬件、升级操作系统或者升级ES大版本。重启所有结点可能带来的一个问题: 某些结点可能先于其他结点加入集群， 先加入集群的结点可能已经可以选举好master，并立即启动了recovery的过程，由于这个时候整个集群数据还不完整，master会指示一些结点之间相互开始复制数据。

那些晚到的结点，一旦发现本地的数据已经被复制到其他结点，则直接删除掉本地“失效”的数据。 当整个集群恢复完毕后，数据分布不均衡，显然是不均衡的，master会触发rebalance过程，将数据在节点之间挪动。

整个过程无谓消耗了大量的网络流量；合理设置recovery相关参数则可以防范这种问题的发生。

gateway.expected_nodes

gateway.expected_master_nodes

gateway.expected_data_nodes

以上三个参数是说集群里一旦有多少个节点就立即开始recovery过程。 不同之处在于，第一个参数指的是master或者data节点都算在内，而后面两个参数则分指master和data node。

在期待的节点数条件满足之前, recovery过程会等待gateway.recover_after_time (默认5分钟) 这么长时间，一旦等待超时，则会根据以下条件判断是否启动:

gateway.recover_after_nodes

gateway.recover_after_master_nodes

gateway.recover_after_data_nodes

举例来说，对于一个有10个data node的集群，如果有以下的设置:

gateway.expected_data_nodes: 10

gateway.recover_after_time: 5m

gateway.recover_after_data_nodes: 8

那么集群5分钟以内10个data node都加入了，或者5分钟以后8个以上的data node加入了，都会立即启动recovery过程。

减少主副本之间的数据复制

如果不是full restart，而是重启单个data node，仍然会造成数据在不同结点之间来回复制。为避免这个问题，可以在重启之前，先关闭集群的shard allocation:

然后在节点重启完成加入集群后，再重新打开:

这样在节点重启完成后，尽量多的从本地直接恢复数据。

但是在ES1.6版本之前，即使做了以上措施，仍然会发现有大量主副本之间的数据拷贝。从表面去看，这点很让人不能理解。 主副本数据完全一致，ES应该直接从副本本地恢复数据就好了，为什么要重新从主片再复制一遍呢？ 原因在于recovery是简单对比主副本的segment file来判断哪些数据一致可以本地恢复，哪些不一致需要远端拷贝的。而不同节点的segment merge是完全独立运行的，可能导致主副本merge的深度不完全一样，从而造成即使文档集完全一样，产生的segment file却不完全一样。

为了解决这个问题，ES1.6版本以后加入了synced flush的新特性。 对于5分钟没有更新过的shard，会自动synced flush一下，实质是为对应的shard加了一个synced flush ID。这样当重启节点的时候，先对比一下shard的synced flush ID，就可以知道两个shard是否完全相同，避免了不必要的segment file拷贝，极大加快了冷索引的恢复速度。

需要注意的是synced flush只对冷索引有效，对于热索引（5分钟内有更新的索引）没有作用。 如果重启的结点包含有热索引，那么还是免不了大量的文件拷贝。因此在重启一个结点之前，最好按照以下步骤执行，recovery几乎可以瞬间完成:

1. 暂停数据写入程序
2. 关闭集群shard allocation
3. 手动执行POST /_flush/synced
4. 重启节点
5. 重新开启集群shard allocation
6. 等待recovery完成，集群health status变成green
7. 重新开启数据写入程序

特大热索引为何恢复慢

对于冷索引，由于数据不再更新，利用synced flush特性，可以快速直接从本地恢复数据。 而对于热索引，特别是shard很大的热索引，除了synced flush派不上用场需要大量跨节点拷贝segment file以外，translog recovery是导致慢的更重要的原因。

从主片恢复数据到副片需要经历3个阶段:

1. 对主片上的segment file做一个快照，然后拷贝到复制片分配到的结点。数据拷贝期间，不会阻塞索引请求，新增索引操作记录到translog里;
2. 对translog做一个快照，此快照包含第一阶段新增的索引请求，然后重放快照里的索引操作。此阶段仍然不阻塞索引请求，新增索引操作记录到translog里;
3. 为了能达到主副片完全同步，阻塞掉新索引请求，然后重放阶段二新增的translog操作。

可见，在recovery完成之前，translog是不能够被清除掉的（禁用掉正常运作期间后台的flush操作）。如果shard比较大，第一阶段耗时很长，会导致此阶段产生的translog很大。重放translog比起简单的文件拷贝耗时要长得多，因此第二阶段的translog耗时也会显著增加。等到第三阶段，需要重放的translog可能会比第二阶段还要多。 而第三阶段是会阻塞新索引写入的，在对写入实时性要求很高的场合，就会非常影响用户体验。 因此，要加快大的热索引恢复速度，最好的方式是遵从上一节提到的方法: 暂停新数据写入，手动sync flush，等待数据恢复完成后，重新开启数据写入，这样可以将数据延迟影响可以降到最低。

万一遇到Recovery慢，想知道进度怎么办呢？ CAT Recovery API可以显示详细的recovery各个阶段的状态。 这个API怎么用就不在这里赘述了，参考: CAT Recovery。

其他Recovery相关的专家级设置

还有其他一些专家级的设置（参考： recovery）可以影响recovery的速度，但提升速度的代价是更多的资源消耗，因此在生产集群上调整这些参数需要结合实际情况谨慎调整，一旦影响应用要立即调整回来。 对于搜索并发量要求高，延迟要求低的场合，默认设置一般就不要去动了。 对于日志实时分析类对于搜索延迟要求不高，但对于数据写入延迟期望比较低的场合，可以适当调大indices.recovery.max_bytes_per_sec，提升recovery速度，减少数据写入被阻塞的时长。

最后要说的一点是ES的版本迭代很快，对于Recovery的机制也在不断的优化中。 其中有一些版本甚至引入了一些bug，比如在ES1.4.x有严重的translog recovery bug，导致大的索引trans log recovery几乎无法完成 （issue #9926） 。因此实际使用中如果遇到问题，最好在Github的issue list里搜索一下，看是否使用的版本有其他人反映同样的问题。

分享阅读参考: https://henduan.com/rCWPD

Elasticsearch是建立在Apache Lucene基础上的实时分布式搜索引擎，Lucene为了提高搜索的实时性，采用不可再修改（immutable）方式将文档存储在一个个segment中。

也就是说，一个segment在写入到存储系统之后，将不可以再修改。那么Lucene是如何从一个segment中删除一个被索引的文档呢？

简单的讲，当用户发出命令删除一个被索引的文档#ABC时，该文档并不会被马上从相应的存储它的segment中删除掉，而是通过一个特殊的文件来标记该文档已被删除。

当用户再次搜索到#ABC时，Elasticsearch在segment中仍能找到#ABC，但由于#ABC文档已经被标记为删除，所以Lucene会从发回给用户的搜索结果中剔除#ABC，所以给用户感觉的是#ABC已经被删除了。

Elasticseach会有后台线程根据Lucene的合并规则定期进行Segment Merging合并操作，一般不需要用户担心或者采取任何行动。

被删除的文档在segment合并时，才会被真正删除掉。在此之前，它仍然会占用着JVM heap和操作系统的文件cache等资源。在某些情况下，我们需要强制Elasticsearch进行segment merging，已释放其占用的大量系统资源。

 POST /{index}/_optimize?only_expunge_deletes=true&wait_for_completion=true

_optimize命令可强制进行segment合并，并删除所有标记为删除的文档。Segment merging要消耗CPU，以及大量的I/O资源，所以一定要在你的ElasticSearch集群处于维护窗口期间，并且有足够的I/O空间的（如：SSD）的条件下进行；否则很可能造成集群崩溃和数据丢失。

下图展示了我们在进行强制expunge时，所观察到的CPU和磁盘I/O的使用情况。该集群运行在微软的Azure云平台IaaS虚拟机上，所有的数据节点都采用 D13 虚拟机，数据存储在本地的SSD磁盘中。该集群是一个备份集群，为了保证合并顺利进行，在此期间暂停了所有对其进行的写操作，仅有少量的读操作。这里需要注意: expunge操作是一种不得已而为之的操作，即在Elasticsearch不能有效自动清除删除文件的情况下才执行该操作。同时建议在此操作期间，最好停止对集群的所有读/写操作，并暂停止shard的自动分配 ( cluster.routing.allocation.enable= none )，以防有节点被踢出后shard自动分配造成的数据丢失。


下面两个设置可以用于控制清除时的处理速度，其中给出值是默认值，可以根据需求进行调整，具体请参见Merge。

此外， 还可以临时将所有索引的replica设置为0，这样只用针对Primary进行expunge，以减小I/O压力。

PUT /{index}/_settings

{

    "settings": {

        "index.merge.policy.expunge_deletes_allowed": "10",

        "index.merge.policy.max_merge_at_once_explicit" : "30" 

    }

}

参考资料：Lucene‘s Handling of Deleted Documents
分享阅读：http://blog.csdn.net/quicknet/article/details/46421505

    ES集群中索引可能由多个分片构成，并且每个分片可以拥有多个副本。通过将一个单独的索引分为多个分片，我们可以处理不能在一个单一的服务器上面运行的大型索引，简单的说就是索引的大小过大，导致效率问题。不能运行的原因可能是内存也可能是存储。由于每个分片可以有多个副本，通过将副本分配到多个服务器，可以提高查询的负载能力。
 
    为了进行分片和副本的操作，ES需要确定将这些分片和副本放到集群节点的哪个位置，就是需要确定把每个分片和副本分配到哪台服务器/节点上。
 

一、显式控制分配

生产情景：

比如生产环境有三个索引分别为 man、woman、katoey

希望达到的效果：

       man索引放置在一些集群节点上   

       woman索引又单独放置到集群的另外一些集群节点上

       katoey索引希望放置在所有放置man索引和woman索引的集群节点上

       

这么做是因为katoey索引比其他两个索引小很多，因此我们可以将它和其他两个索引一起分配。

但是基于ES默认算法的处理方法，我们不能确定分片和副本的存放位置，但是ES允许我们对其做相应的控制！

1、指定节点的参数
    如上图所示，我们将ES集群划分为两个"空间"。当然你也可以叫做区域，随便命名。我们将左边的三台ES节点服务器放置到zone_one的空间上面，将右边的三台ES节点服务器放到zone_two的空间上。
 
配置
    为了做到我们需要的效果，我们需要将如下属性配置到左边三台ES集群节点服务器的elasticsearch.yml配置文件中

node.zone: zone_one

    将如下属性配置到右边的三台ES集群节点服务器elasticsearch.yml配置文件中

node.zone: zone_two

 
索引创建
    当所有节点配置文件属性配置完成后，我们就可以根据空间名称，我们就可以创建索引放到指定的空间。
    首先我们运行如下命令，来创建man索引：

# curl -XPOST "http://ESnode:9200/man'

# curl -XPUT "http://ESnode:9200/man/_settings' -d '{

   "index.routing.allocation.include.zone" : "zone_one"

   }'

    第一条命令是创建man索引；第二条命令是发送到_settings REST端点，用来指定这个索引的其他配置信息。我们将index.routing.allocation.include.zone属性设置为zone_one值，就是我们所希望的把man索引放置到node.zone属性值为zone_one的ES集群节点服务器上。
 
    同样对woman索引我们做类似操作：

# curl -XPOST "http://ESnode:9200/woman'

# curl -XPUT "http://ESnode:9200/woman/_settings' -d '{

   "index.routing.allocation.include.zone" : "zone_two"

   }'

    不同的是，这次指定woman索引放置在node.zone属性值为zone_two的ES集群节点服务器上
 
    最后我们需要将katoey索引放置到上面所有的ES集群节点上面，配置设置命令如下：

# curl -XPOST "http://ESnode:9200/katoey"

# curl -XPUT "http://ESnode:9200/katoey/_settings" -d '{

  "index.routing.allocation.include.zone" : "zone_one,zone_two"

  }'

 2、分配时排除节点
    跟我们上面操作为索引指定放置节点位置一样，我们也可以在索引分配的时候排除某些节点。参照之前的例子，我们新建一个people索引，但是不希望people索引放置到zone_one的ES集群节点服务器上，我们可以运行如下命令操作：

# curl -XPOST "http://EScode:9200/people"

# curl -XPUT "http://EScode:9200/people/_settings" -d '{

  "index.routing.allocation.exclude.zone" : "zone_one"

  }'

    请注意，在这里我们使用的是index.routing.allocation.exclude.zone属性而不是index.routing.allocation.include.zone属性。
 
使用IP地址进行分配配置
    除了在节点的配置中添加一些特殊的属性参数外，我们还可以使用IP地址来指定你将分片和副本分配或者不分配到哪些节点上面。为了做到这点，我们应该使用_ip属性，把zone换成_ip就好了。例如我们希望lucky索引分配到IP地址为10.0.1.110和10.0.1.119的节点上，我们可以运行如下命令设置：

# curl -XPOST "http://ESnode:9200/lucky"

# curl -XPUT "http://ESnode:9200/lucky/_settings" -d '{

  "index.routing.allocation.include._ip" "10.0.1.110,10.0.1.119"

  }'

二、集群范围内分配

    除了索引层面指定分配活着排除分配之外(上面我们所做的都是这两种情况),我们还可以指定集群中所有索引的分配。例如，我们希望将所有的新索引分配到IP地址为10.0.1.112和10.0.1.114的节点上，我们可以运行如下命令设置：

# curl -XPUT "http://ESnode:9200/_cluster/settings" -d '{

  "transient" : {

   "cluster.routing.allocation.include._ip" "10.0.1.112,10.0.1.114"

   }

  }'

    集群级别的控制后续还会分享transient和persistent属性介绍
 

三、每个节点上分片和副本数量的控制

    除了指定分片和副本的分配，我们还可以对一个索引指定每个节点上的最大分片数量。例如我们希望ops索引在每个节点上只有一个分片，我们可以运行如下命令：

# curl -XPUT "http://ESnode:9200/ops/_settings" -d '{

  "index.routing.allocation.total_shards_per_node" : 1

  }'

    这个属性也可以直接配置到elasticsearch.ym配置文件中，或者使用上面命令在活动索引上更新。如果配置不当，导致主分片无法分配的话，集群就会处于red状态。
 

四、手动移动分片和副本

    接下来我们介绍一下节点间手动移动分片和副本。可以使用ElasticSearch提供的_cluster/reroute REST端点进行控制，能够进行下面操作：

[]将一个分片从一个节点移动到另外一个节点[/][]取消对分片的分配[/][]强制对分片进行分配[/]

 
移动分片
    假设我们有两个节点：es_node_one和es_node_two，ElasticSearch在es_node_one节点上分配了ops索引的两个分片，我们现在希望将第二个分片移动到es_node_two节点上。可以如下操作实现：

# curl -XPOST "http://ESnode:9200/_cluster/reroute" -d  '{

   "commands" : [ {

   "move" : {

   "index" : "ops",

   "shard" : 1,

   "from_node" : "es_node_one",

   "to_node" : "es_node_two"

   }

  }]

  }'

    我们通过move命令的index属性指定移动哪个索引,通过shard属性指定移动哪个分片，最终通过from_node属性指定我们从哪个节点上移动分片，通过to_node属性指定我们希望将分片移动到哪个节点。
 
取消分配
    如果希望取消一个正在进行的分配过程，我们通过运行cancel命令来指定我们希望取消分配的索引、节点以及分片，如下所示：

# curl -XPOST "http://ESnode:9200/_cluster/reroute" -d '{

  "commands" : [ {

  "cancel" : {

  "index" : "ops",

  "shard" : 0,

  "node" : "es_node_one"

  }

  } ]

  }'

    运行上面的命令将会取消es_node_one节上ops索引的第0个分片的分配
 
分配分片
    除了取消和移动分片和副本之外，我们还可以将一个未分配的分片分配到一个指定的节点上。假设ops索引上有一个编号为0的分片尚未分配，并且我们希望ElasticSearch将其分配到es_node_two上，可以运行如下命令操作：

# curl -XPOST "http://ESnode:9200/_cluster/reroute' -d '{

  "commands" : [ {

   "allocate" : {

    "index" : "ops",

    "shard" : 0,

    "node" : "es_node_two"

    }

   } ]

   }'

一次HTTP请求包含多个命令
    我们可以在一次HTTP请求中包含多个命令，例如：

# curl -XPOST "http://ESnode:9200/_cluster/reroute" -d '{

   "commands" : [

     {"move" : {"index" : "ops", "shard" : 1, "from_node" : "es_node_one", "to_node" : "es_node_two"}},

     {"cancel" : {"index" : "ops", "shard" : 0, "node" : "es_node_one"}}

    ]

 }'

一、Elasticseach如何将数据存储到分片中

问题：当我们要在ES中存储数据的时候，数据应该存储在主分片和复制分片中的哪一个中去；当我们在ES中检索数据的时候，又是怎么判断要查询的数据是属于哪一个分片。

数据存储到分片的过程是一定规则的，并不是随机发生的。

规则：shard = hash(routing) % number_of_primary_shards

Routing值可以是一个任意的字符串，默认情况下，它的值为存数数据对应文档 _id 值，也可以是用户自定义的值。Routing这个字符串通过一个hash的函数处理，并返回一个数值，然后再除以索引中主分片的数目，所得的余数作为主分片的编号，取值一般在0到number_of_primary_shards - 1的这个范围中。通过这种方法计算出该数据是存储到哪个分片中。

正是这种路由机制，导致了主分片的个数为什么在索引建立之后不能修改。对已有索引主分片数目的修改直接会导致路由规则出现严重问题，部分数据将无法被检索。

二、主分片与复制分片如何交互

为了说明这个问题，我用一个例子来说明。

在上面这个例子中，有三个ES的node，其中每一个index中包含两个primary shard，每个primary shard拥有2个replica shard。下面从几种常见的数据操作来说明二者之间的交互情况。

1、索引与删除一个文档

这两种过程均可以分为三个过程来描述：
阶段1：客户端发送了一个索引或者删除的请求给node 1。

阶段2：node 1通过请求中文档的 _id 值判断出该文档应该被存储在shard 0 这个分片中，并且node 1知道shard 0的primary shard位于node 3这个节点上。因此node 1会把这个请求转发到node 3。

阶段3：node 3在shard 0 的primary shard上执行请求。如果请求执行成功，它node 3将并行地将该请求发给shard 0的其余所有replica shard上，也就是存在于node 1和node 2中的replica shard。如果所有的replica shard都成功地执行了请求，那么将会向node 3回复一个成功确认，当node 3收到了所有replica shard的确认信息后，则最后向用户返回一个Success的消息。

2、更新一个文档

该过程可以分为四个阶段来描述：
阶段1：客户端向node 1发送一个文档更新的请求。

阶段2：同样的node 1通过请求中文档的 _id 值判断出该文档应该被存储在shard 0 这个分片中，并且node 1知道shard 0的primary shard位于node 3这个节点上。因此node 1会把这个请求转发到node 3。

阶段3：node 3从文档所在的primary shard中获取到它的JSON文件，并修改其中的_source中的内容，之后再重新索引该文档到其primary shard中。

阶段4：如果node 3成功地更新了文档，node 3将会把文档新的版本并行地发给其余所有的replica shard所在node中。这些node也同样重新索引新版本的文档，执行后则向node 3确认成功，当node 3接收到所有的成功确认之后，再向客户端发送一个更新成功的信息。

3、检索文档
CRUD这些操作的过程中一般都是结合一些唯一的标记例如：_index，_type，以及routing的值，这就意味在执行操作的时候都是确切的知道文档在集群中的哪个node中，哪个shard中。

而检索过程往往需要更多的执行模式，因为我们并不清楚所要检索的文档具体位置所在， 它们可能存在于ES集群中个任何位置。因此，一般情况下，检索的执行不得不去询问index中的每一个shard。

但是，找到所有匹配检索的文档仅仅只是检索过程的一半，在向客户端返回一个结果列表之前，必须将各个shard发回的小片的检索结果，拼接成一个大的已排好序的汇总结果列表。正因为这个原因，检索的过程将分为查询阶段与获取阶段（Query Phase and Fetch Phase）。

Query Phase
在最初的查询过程中，查询请求会广播到index中的每一个primary shard和replica shard中，每一个shard会在本地执行检索，并建立一个优先级队列（priority queue）。这个优先级队列是一个根据文档匹配度这个指标所排序列表，列表的长度由分页参数from和size两个参数所决定。例如：

下面从一个例子中说明这个过程：

Query Phase阶段可以再细分成3个小的子阶段：

子阶段1：客户端发送一个检索的请求给node 3，此时node 3会创建一个空的优先级队列并且配置好分页参数from与size。

子阶段2：node 3将检索请求发送给该index中个每一个shard（这里的每一个意思是无论它是primary还是replica，它们的组合可以构成一个完整的index数据）。每个shard在本地执行检索，并将结果添加到本地优先级队列中。

子阶段3：每个shard返回本地优先级序列中所记录的_id与sort值，并发送node 3。Node 3将这些值合并到自己的本地的优先级队列中，并做全局的排序。

Fetch Phase
Query Phase主要定位了所要检索数据的具体位置，但是我们还必须取回它们才能完成整个检索过程。而Fetch Phase阶段的任务就是将这些定位好的数据内容取回并返回给客户端。

同样也用一个例子来说明这个过程：

Fetch Phase过程可以分为三个子过程来描述：

子阶段1：node 3获取了所有待检索数据的定位之后，发送一个mget的请求给与数据相关的shard。

子阶段2：每个收到node 3的get请求的shard将读取相关文档_source中的内容，并将它们返回给node 3。

子阶段3：当node 3获取到了所有shard返回的文档后，node 3将它们合并成一条汇总的结果，返回给客户端。

参考： https://www.elastic.co/guide/cn/elasticsearch/guide/current/how-primary-and-replica-shards-interact.html

启动内存问题

Java HotSpot(TM) 64-Bit Server VM warning: INFO: os::commit_memory(0x0000000085330000, 2060255232, 0) failed; error='Cannot allocate memory' (errno=12)

分析: 默认分配的JVM内存为2g，所以当小内存的机器，默认启动的话，会报如上错误。

解决: 修改Eleasticsearch启动JVM内存参数, 修改文件: config/jvm.options

-Xms2g  

-Xmx2g



修改为



-Xms1g

-Xmx1g

对于内存较低的云主机和虚拟机，你要测试Elasticsearch的基本功能，没有太大性能要求的话，这时候就需要修改启动内存。

启动用户问题

don't run elasticsearch as root

分析: 程序设计者，出于系统安全考虑设置的条件， 由于ElasticSearch可以接收用户输入的脚本并且执行，为了系统安全考虑，如果获取root权限了，那问题就打了，所以默认官方是建议创建一个单独的用户用来运行ElasticSearch。

解决：添加单独的用户运行

groupadd es

useradd es -g es

更改elasticsearch文件夹及内部文件的所属用户及组为es:es

chown -R es:es  elasticsearch

切换到es用户启动：

su - es

./bin/elasticsearch -d



# 或者root下

su es -c "/opt/elasticsearch/bin/elasticsearch -d"

Tips: ES5版本之前，还可以修改ES_JAVA_OPTS启动参数，加上-Des.insecure.allow.root=true 可以使用root启动，但是不推荐这么玩。

最大虚拟内存区域问题

 max virtual memory areas vm.max_map_count [256000] is too low, increase to at least [262144]

什么是VMA(virtual memory areas):

This file contains the maximum number of memory map areas a process may have. Memory map areas are used as a side-effect of calling malloc, directly by mmap and mprotect, and also when loading shared libraries.



While most applications need less than a thousand maps, certain programs, particularly malloc debuggers, may consume lots of them, e.g., up to one or two maps per allocation.



The default value is 65536

max_map_count文件包含限制一个进程可以拥有的VMA(虚拟内存区域)的数量。虚拟内存区域是一个连续的虚拟地址空间区域。在进程的生命周期中，每当程序尝试在内存中映射文件，链接到共享内存段，或者分配堆空间的时候，这些区域将被创建。调优这个值将限制进程可拥有VMA的数量。限制一个进程拥有VMA的总数可能导致应用程序出错，因为当进程达到了VMA上线但又只能释放少量的内存给其他的内核进程使用时，操作系统会抛出内存不足的错误。如果你的操作系统在NORMAL区域仅占用少量的内存，那么调低这个值可以帮助释放内存给内核用。

解决:

# 临时设置

sysctl -w vm.max_map_count=262144



# 永久设置

echo "vm.max_map_count=262144" >> /etc/sysctl.conf

sysctl -p

虚拟内存最大大小问题

max size virtual memory [67108864] for user [es] is too low, increase to [unlimited]

分析：引用官网的说法

The segment files that are the components of individual shards and the translog generations that are components of the translog can get large (exceeding multiple gigabytes). On systems where the max size of files that can be created by the Elasticsearch process is limited, this can lead to failed writes. Therefore, the safest option here is that the max file size is unlimited and that is what the max file size bootstrap check enforces. To pass the max file check, you must configure your system to allow the Elasticsearch process the ability to write files of unlimited size.

地址：https://www.elastic.co/guide/en/elasticsearch/reference/master/max-size-virtual-memory-check.html#max-size-virtual-memory-check

解决：

echo "* - as unlimited" >> /etc/security/limits.conf

echo "root - as unlimited" >> /etc/security/limits.conf

参考: https://stackoverflow.com/questions/42510873/vm-max-map-count-is-too-low

最大文件描述符问题

max file descriptors [4096] for elasticsearch process is too low, increase to at least [65536]

分析：elasticsearch启动bootstrap checks要求系统打开最大系统文件描述符为65536

解决：

# 临时 ulimit -f unlimited

echo "* soft nofile 65536" >>  /etc/security/limits.conf

echo "* hard nofile 65536" >>  /etc/security/limits.conf

确认:

ulimit -Hn

ulimit -Sn

最大线程数问题

max number of threads [3818] for user [es] is too low, increase to at least [4096]

分析：elasticsearch启动bootstrap checks要求打开最大线程数最低为4096

解决:

echo "* soft nproc 65535"  >> /etc/security/limits.conf

echo "* hard nproc 65535"  >> /etc/security/limits.conf

注意：修改这里，普通用户max user process值是不生效的，需要修改/etc/security/limits.d/20-nproc.conf文件中的值。Centos6系统的是是90-nproc.conf文件。

修改 /etc/security/limits.d/20-nproc.conf

*   soft   nproc   65535

系统总限制

其实上面的 max user processes 65535 的值也只是表象，普通用户最大进程数无法达到65535 ，因为用户的max user processes的值，最后是受全局的kernel.pid_max的值限制。
也就是说kernel.pid_max=1024 ，那么你用户的max user processes的值是65535 ，用户能打开的最大进程数还是1024。

# 临时生效

echo 65535 > /proc/sys/kernel/pid_max

sysctl -w kernel.pid_max=65535



# 永久生效

echo "kernel.pid_max = 65535" >> /etc/sysctl.conf

sysctl -p

然后重启机器生效。

参考: https://www.cnblogs.com/xidianzxm/p/11820706.html

确认:

ulimit -Hu

ulimit -Su

运行目录权限问题

Exception in thread "main" java.nio.file.AccessDeniedException: /opt/elasticsearch-6.2.2-1/config/jvm.options

分析: es用户没有该文件夹的权限

解决：

chown es.es /opt/elasticsearch-6.2.2-1 -R

如果还有碰到其他问题的同学，可以留言补充。

ES 有Master节点和Data节点，Master节点什么意思呢？ 就是主人节点，这个集群的主人，就是皇帝。ES同一时刻只有一个Master节点。小生一直看古装走火入魔，所谓心里有王朝，眼里就有王朝，看啥啥是王朝。就用王朝解释下集群，皇帝比喻下Master。我们先来看2个配置项。
 
node.master: true  就是皇子，意思是有资格成为Master,成为皇帝的人选，这是天生的，是无字天书，在elasticsearch.yml里写好的。

discovery.zen.minimum_master_nodes: 1 就是几个皇子在场的时候，才能选新皇帝，不然难以服众，容易脑裂（brain split）是吧。
 

Master的职责

只有皇帝才有资格发布圣旨ClusterState(集群状态)。他维护着这个王朝的状态，决定着这个王朝很多重要的大小事物。有一些事情必须皇帝才能执行，比如砍头（删除索引）。但是ES作为P2P集群，Master的职责，还是被弱化了一些。一张图看一下皇帝的工作内容。


 

什么时候选Master

只有在皇帝驾崩，和王朝诞生的时候，才选举Master皇帝，是吧，想让皇帝禅位，除非他死了，或者王朝被推翻了（所有节点重启）

 
节点启动，要加入一个集群的时候
 

//ZenDiscovery

private void innterJoinCluster() {

        boolean retry = true;

        while (retry) {

            if (lifecycle.stoppedOrClosed()) {

                return;

            }

            retry = false;

            DiscoveryNode masterNode = findMaster(); //找一个节点出来当皇帝

            if (masterNode == null) {

                logger.trace("no masterNode returned");

                retry = true;

                continue;

            }

            //....

或者节点关闭 Master Gone

private void handleMasterGone(final DiscoveryNode masterNode, final String reason) {

 if (lifecycleState() != Lifecycle.State.STARTED) {

            return;

        }

        if (master) {

            return;

        }

        logger.info("master_left [{}], reason [{}]", masterNode, reason);

        clusterService.submitStateUpdateTask("zen-disco-master_failed (" + masterNode + ")", Priority.HIGH, new ProcessedClusterStateUpdateTask() {

            @Override

            public ClusterState execute(ClusterState currentState) {

                if (!masterNode.id().equals(currentState.nodes().masterNodeId())) {

                    return currentState;

                }

                DiscoveryNodes.Builder nodesBuilder = DiscoveryNodes.newNodesBuilder()

                        .putAll(currentState.nodes())

                        .remove(masterNode.id())

                        .masterNodeId(null);

                if (!electMaster.hasEnoughMasterNodes(nodesBuilder.build())) {

                    return rejoin(ClusterState.builder().state(currentState).nodes(nodesBuilder).build(), "not enough master nodes after master left (reason = " + reason + ")");

                }

                final DiscoveryNode electedMaster = electMaster.electMaster(nodesBuilder.build()); // 选举Master

 

Master选举

首先必须是皇子(node.master: true)，具体哪皇子成为皇帝呢？ 看天意啊，最先启动的那个节点。老臣认为。当立嫡长子为太子，成为皇帝啊，这样江山社稷才能稳固啊，（一阵激动）省略上万句。。。好了，演完戏了，看代码。

 
ZenDiscovery模块启动的时候，要加入集群。findMaster 方法里，Ping一堆节点出来，Ping就是发现节点，这里的Ping不是Linux的命令Ping，是向ES的9300端口发送数据的意思。Linux的Ping是可以禁止的，不能因为命令Ping不通机器，就认为相互不能发现节点。Ping有组播MulticastZenPing和单播UnicastZenPing 两种。如果节点少，用单播也可以。组播在一些环境下可能无法相互发现节点，或者被安全软件识别为恶意程序。节点列表确定后。交给 ElectMasterService 去选举，快排后的第一个节点

//ElectMasterService

    /**

     * Elects a new master out of the possible nodes, returning it. Returns null

     * if no master has been elected.

     */

    public DiscoveryNode electMaster(Iterable nodes) {

        List sortedNodes = sortedMasterNodes(nodes);

        if (sortedNodes == null || sortedNodes.isEmpty()) {

            return null;

        }

        return sortedNodes.get(0);

    }



    private List sortedMasterNodes(Iterable nodes) {

        List possibleNodes = Lists.newArrayList(nodes);

        if (possibleNodes.isEmpty()) {

            return null;

        }

        // clean non master nodes

        for (Iterator it = possibleNodes.iterator(); it.hasNext(); ) {

            DiscoveryNode node = it.next();

            if (!node.masterNode()) {

                it.remove();

            }

        }

        CollectionUtil.quickSort(possibleNodes, nodeComparator);

        return possibleNodes;

    }

对了，皇帝上位以后，第一件事情是发布圣旨，昭告天下，以后寡人就是皇帝了。

怎么看，现在谁是皇帝呢？
 

curl http://localhost:9200/_cat/master?v

脑裂问题
 
关于brain split脑裂问题，可以看这个:
如何避免脑裂: http://blog.trifork.com/2013/10/24/how-to-avoid-the-split-brain-problem-in-elasticsearch/  
官方讨论：https://github.com/elasticsearch/elasticsearch/issues/2488 
 
最后，为了让大家对皇帝有个感性的认识，赠图一张，不谢！

原文分享：http://www.codeweblog.com/elasticsearch-%E6%BA%90%E4%BB%A3%E7%A0%81%E5%88%86%E6%9E%90%E4%B9%8Bmaster%E9%80%89%E4%B8%BE/ 

摘要

在Elasticsearch中节点可以分为主(master)节点，数据(data)节点，客户端节点和部落节点，每种类型的节点有不同的使用方法，对于一个大的集群中，合理的配置这些属性，对集群的健壮性和性能有很大的帮助。
 

节点类型

当我们启动Elasticsearch的实例，就会启动至少一个节点。相同集群名的多个节点的连接就组成了一个集群，在默认情况下，集群中的每个节点都可以处理http请求和集群节点间的数据传输，集群中所有的节点都知道集群中其他所有的节点，可以将客户端请求转发到适当的节点。节点有以下类型：

• 主(master)节点：在一个节点上当node.master设置为True（默认）的时候，它有资格被选作为主节点，控制整个集群。
• 数据(data)节点：在一个节点上node.data设置为True（默认）的时候。该节点保存数据和执行数据相关的操作，如增删改查，搜索，和聚合。
• 客户端节点：当一个节点的node.master和node.data都设置为false的时候，它既不能保持数据也不能成为主节点，该节点可以作为客户端节点，可以响应用户的情况，并把相关操作发送到其他节点。
• 部落节点： 当一个节点配置tribe.*的时候，它是一个特殊的客户端，它可以连接多个集群，在所有连接的集群上执行搜索和其他操作。

 
默认情况下，节点配置是一个主节点和一个数据节点。这是非常方便的小集群，但随着集群的发展，分离主节点和数据节点将变得很重要。
 
大家知道Elasticsearch的data node除了放数据以外，也可以兼任master和client的角色，多数同学会将这些角色混入到data node。然而对于一个规模较大，用户较多的集群，master和client在一些极端使用情况下可能会有性能瓶颈甚至内存溢出，从而使得共存的data node故障。data node的故障恢复涉及到数据的迁移，对集群资源有一定消耗，容易造成数据写入延迟或者查询减慢。如果将master和client独立出来，一旦出现问题，重启后几乎是瞬间就恢复的，对用户几乎没有任何影响。另外将这些角色独立出来的以后，也将对应的计算资源消耗从data node剥离出来，更容易掌握data node资源消耗与写入量和查询量之间的联系，便于做容量管理和规划。
 

主(Master)节点说明

主节点的主要职责是和集群操作相关的内容，如创建或删除索引，跟踪哪些节点是群集的一部分，并决定哪些分片分配给相关的节点。稳定的主节点对集群的健康是非常重要的。默认情况下任何一个集群中的节点都有可能被选为主节点。索引数据和搜索查询等操作会占用大量的cpu，内存，io资源，为了确保一个集群的稳定，分离主节点和数据节点是一个比较好的选择。
 
虽然主节点也可以协调节点，路由搜索和从客户端新增数据到数据节点，但最好不要使用这些专用的主节点。一个重要的原则是，尽可能做尽量少的工作。创建一个独立的主节点只需在配置文件中添加如下内容：

node.master: true 

node.data: false

为了防止数据丢失，配置discovery.zen.minimum_master_nodes设置是至关重要的（默认为1），每个主节点应该知道形成一个集群的最小数量的主资格节点的数量。解释如下：
 
假设我们有一个集群。有3个主资格节点，当网络发生故障的时候，有可能其中一个节点不能和其他节点进行通信了。这个时候，当discovery.zen.minimum_master_nodes设置为1的时候，就会分成两个小的独立集群，当网络好的时候，就会出现数据错误或者丢失数据的情况。当discovery.zen.minimum_master_nodes设置为2的时候，一个网络中有两个主资格节点，可以继续工作，另一部分，由于只有一个主资格节点，则不会形成一个独立的集群，这个时候当网络回复的时候，节点又会从新加入集群。设置这个值的原则是：

（master_eligible_nodes / 2）+ 1

这个参数也可以动态设置：

PUT localhost:9200/_cluster/settings

{

  "transient": {

    "discovery.zen.minimum_master_nodes": 2

  }

}

数据节点说明

数据节点主要是存储索引数据的节点，主要对文档进行增删改查操作，聚合操作等。数据节点对cpu，内存，io要求较高，在优化的时候需要监控数据节点的状态，当资源不够的时候，需要在集群中添加新的节点。数据节点的配置如下：

node.master: false 

node.data: true

数据节点路径设置,每一个主节点和数据节点都需要知道分片，索引，元数据的物理存储位置，path.data默认位为 $ES_HOME/data，可以通过配置文件 elasticsearch.yml进行修改，例如:

path.data:  /data/es/data/

这个设置也可以在命令行上执行，例如：

./bin/elasticsearch --path.data /data/es/data

这个路径最好进行单独配置，这样Elasticsearch的目录和数据的目录就会分开。当删除了Elasticsearch主目录的时候，不会影响到数据。通过rpm安装默认是分开的。
 
数据目录可以被多个节点共享，甚至可以属于不同的集群，为了防止多个节点共享相同的数据路径，可以在配置文件elasticsearch.yml中添加：node.max_local_storage_nodes: 1
 
注意：在相同的数据目录不要运行不同类型的节点（例如：master, data, client）这很容易导致意外的数据丢失。
 

客户端节点说明

当主节点和数据节点配置都设置为false的时候，该节点只能处理路由请求，处理搜索，分发索引操作等，从本质上来说该客户节点表现为智能负载平衡器。独立的客户端节点在一个比较大的集群中是非常有用的，他协调主节点和数据节点，客户端节点加入集群可以得到集群的状态，根据集群的状态可以直接路由请求。

警告：添加太多的客户端节点对集群是一种负担，因为主节点必须等待每一个节点集群状态的更新确认！客户节点的作用不应被夸大 ， 数据节点也可以起到类似的作用。配置如下：

node.master: false 

node.data: false

部落节点说明

部落节点可以跨越多个集群，它可以接收每个集群的状态，然后合并成一个全局集群的状态，它可以读写所有节点上的数据，部落节点在elasticsearch.yml中的配置如下：

tribe:

    t1: 

        cluster.name:   cluster_one

    t2: 

        cluster.name:   cluster_two

T1和T2是任意的名字代表连接到每个集群。上面的示例配置两集群连接，名称分别是T1和T2。默认情况下部落节点通过广播可以做为客户端连接每一个集群。大多数情况下，部落节点可以像单节点一样对集群进行操作。
 
注意：以下操作将和单节点操作不同，
如果两个集群的名称相同，部落节点只会连接其中一个。由于没有主节点，当设置local为true的是，主节点的读操作会被自动的执行，例如：集群统计，集群健康度。主节点级别的写操作将被拒绝，这些应该是在一个集群进行。部落节点可以通过块(block)设置所有的写操作和所有的元数据操作，例如：

tribe:

    blocks:

        write:    true

        metadata: true

部落节点可以也可以在选中的索引块中进行配置，例如：

tribe:

    blocks:

        write.indices:    hk*,ldn*

        metadata.indices: hk*,ldn*

当多个集群有相同的索引名的时候，默认情况下，部落的节点将选择其中一个。这可以通过tribe.on_conflict setting进行配置，可以设置排除那些索引或者指定固定的部落名称。

Elasticsearch简述

ElasticSearch是现在技术前沿的大数据引擎，常见的组合有ES+Logstash+Kibana作为一套成熟的日志系统，其中Logstash是ETL工具，Kibana是数据分析展示平台。Elasticsearch让人惊艳的是他强大的搜索相关能力和灾备策略，Elastcisearch开放了一些接口供开发者研发自己的插件，Elasticsearch结合中文分词的插件会给Elasticsearch的搜索和分析起到很大的推动作用。ElasticSearch是使用开源全文检索库Apache Lucene进行索引和搜索的，所以Elasticsearch底层是依赖的Lucene。
 
关于Lucene：
Apache Lucene将写入索引的所有信息组织成一种倒排索引（Inverted Index）的结构之中，该结构是种将词项映射到文档的数据结构。其工作方式与传统的关系数据库不同，大致来说倒排索引是面向词项而不是面向文档的。且Lucene索引之中还存储了很多其他的信息，如词向量等等，每个Lucene都是由多个段构成的，每个段只会被创建一次但会被查询多次，段一旦创建就不会再被修改。多个段会在段合并的阶段合并在一起，何时合并由Lucene的内在机制决定，段合并后数量会变少，但是相应的段本身会变大。段合并的过程是非常消耗I/O的，且与之同时会有些不再使用的信息被清理掉。在Lucene中，将数据转化为倒排索引，将完整串转化为可用于搜索的词项的过程叫做分析。文本分析由分析器（Analyzer）来执行，分析其由分词器（Tokenizer），过滤器（Filter）和字符映射器（Character Mapper）组成，其各个功能显而易见。除此之外，Lucene有自己的一套完整的查询语言来帮助我们进行搜索和读写。
 
*注：Elasticsearch中的索引指的是查询/寻址时URI中的一个字段如：[host]：[port（9200）]/[index]/[type]/[ID]?[option]，而Lucene中的索引更多地和ES中的分片的概念相对应。
 
Elasticsearch架构设计理念特性如下：

1. 合理的默认配置：只需修改节点中的Yaml配置文件，就可以快速配置。这和Spring4中对配置的简化有相似的地方。
2. 分布式工作模式：Elasticsearch强大的Zen发现机制不仅支持组广播也支持点单播，且有“知一点即知天下”之妙。
3. 对等架构：节点之间自动备份分片，且使分片本身和样本之间尽量”远离“，可以避免单点故障。且Master节点和Data节点几乎完全等价。
4. 易于向集群扩充新节点：大大简化研发或运维将新节点加入集群所需的工作。
5. 不对索引中的数据结构增加任何限制：ES支持在一个索引之中存在多种数据类型。
6. 准实时：搜索和版本同步，由于ES是分布式应用，一个重大的挑战就是一致性问题，无论索引还是文档数据，然而事实证明ES表现优秀。

 

分片策略

选择合适的分片数和副本数：
ES的分片分为两种，主分片（Primary Shard）和副本（Replicas）。默认情况下，ES会为每个索引创建5个分片，即使是在单机环境下，这种冗余被称作过度分配（Over Allocation），目前看来这么做完全没有必要，仅在散布文档到分片和处理查询的过程中就增加了更多的复杂性，好在ES的优秀性能掩盖了这一点。假设一个索引由一个分片构成，那么当索引的大小超过单个节点的容量的时候，ES不能将索引分割成多份，因此必须在创建索引的时候就指定好需要的分片数量。此时我们所能做的就是创建一个新的索引，并在初始设定之中指定这个索引拥有更多的分片。反之如果过度分配，就增大了Lucene在合并分片查询结果时的复杂度，从而增大了耗时，所以我们得到了以下结论： 我们应该使用最少的分片！
 
主分片，副本和节点最大数之间数量存在以下关系：

节点数 <= 主分片数 *（副本数+1）    NodeNum <= PNum * ( Rnum + 1 )

这个关系，其实就是保持最好一个数据节点，最好保存一个索引的一个分片（不管主副）。
 
控制分片分配行为：
以上是在创建每个索引的时候需要考虑的优化方法，然而在索引已创建好的前提下，是否就是没有办法从分片的角度提高了性能了呢？当然不是，首先能做的是调整分片分配器的类型，具体是在elasticsearch.yml中设置cluster.routing.allocation.type属性，共有两种分片器even_shard,balanced（默认）。even_shard是尽量保证每个节点都具有相同数量的分片，balanced是基于可控制的权重进行分配，相对于前一个分配器，它更暴漏了一些参数而引入调整分配过程的能力。
 
每次ES的分片调整都是在ES上的数据分布发生了变化的时候进行的，最有代表性的就是有新的数据节点加入了集群的时候。当然调整分片的时机并不是由某个阈值触发的，ES内置十一个裁决者来决定是否触发分片调整，这里暂不赘述。另外，这些分配部署策略都是可以在运行时更新的，更多配置分片的属性也请大家自行Google。
 

路由优化

ES中所谓的路由和IP网络不同，是一个类似于Tag的东西。在创建文档的时候，可以通过字段为文档增加一个路由属性的Tag。ES内在机制决定了拥有相同路由属性的文档，一定会被分配到同一个分片上，无论是主分片还是副本。那么，在查询的过程中，一旦指定了感兴趣的路由属性，ES就可以直接到相应的分片所在的机器上进行搜索，而避免了复杂的分布式协同的一些工作，从而提升了ES的性能。于此同时，假设机器1上存有路由属性A的文档，机器2上存有路由属性为B的文档，那么我在查询的时候一旦指定目标路由属性为A，即使机器2故障瘫痪，对机器1构不成很大影响，所以这么做对灾况下的查询也提出了解决方案。所谓的路由，本质上是一个分桶（Bucketing）操作。当然，查询中也可以指定多个路由属性，机制大同小异。
 

Elasticsearch GC调优

ElasticSearch本质上是个Java程序，所以配置JVM垃圾回收器本身也是一个很有意义的工作。我们使用JVM的Xms和Xmx参数来提供指定内存大小，本质上提供的是JVM的堆空间大小，当JVM的堆空间不足的时候就会触发致命的OutOfMemoryException。这意味着要么内存不足，要么出现了内存泄露。处理GC问题，首先要确定问题的源头，一般有三种方案：

1. 开启ElasticSearch上的GC日志
2.  使用jstat命令
3. 生成内存Dump

第一条，在ES的配置文件elasticsearch.yml中有相关的属性可以配置，关于每个属性的用途这里当然说不完。
第二条，jstat命令可以帮助我们查看JVM堆中各个区的使用情况和GC的耗时情况。
第三条，最后的办法就是将JVM的堆空间转储到文件中去，实质上是对JVM堆空间的一个快照。

想了解更多关于JVM本身GC调优方法请参考：http://www.oracle.com/technetwork/java/javase/gc-tuning-6-140523.html 

另外，通过修改ES节点的启动参数，也可以调整GC的方式，但是实质上和上述方法是等同的。
 

避免内存交换

这一点很简单，由于操作系统的虚拟内存页交换机制，会给性能带来障碍，如数据写满内存会写入Linux中的Swap分区。

可以通过在elasticsearch.yml文件中的bootstrap.mlockall设置为true来实现，但是需要管理员权限，需要修改操作系统的相关配置文件。
 

控制索引合并

上文提到过，ES中的分片和副本本质上都是Lucene索引，而Lucene索引又基于多个索引段构建（至少一个），索引文件中的绝大多数都是只被写一次，读多次，在Lucene内在机制控制下，当满足某种条件的时候多个索引段会被合并到一个更大的索引段，而那些旧的索引段会被抛弃并移除磁盘，这个操作叫做段合并。 

Lucene要执行段合并的理由很简单充分：索引段粒度越小，查询性能越低且耗费的内存越多。频繁的文档更改操作会导致大量的小索引段，从而导致文件句柄打开过多的问题，如修改系统配置，增大系统允许的最大文件打开数。总的来讲，当索引段由多一个合并为一个的时候，会减少索引段的数量从而提高ES性能。对于研发者来讲，我们所能做的就是选择合适的合并策略，尽管段合并完全是Lucene的任务，但随着Lucene开放更多配置借口，新版本的ES还是提供了三种合并的策略tiered，log_byte_size，log_doc。另外，ES也提供了两种Lucene索引段合并的调度器：concurrent和serial。其中各者具体区别，这里暂不赘述，只是抛砖引玉。

分享阅读原文：http://www.cnblogs.com/guguli/p/5218297.html

Elasticsearch中常用API分类

elasticsearch中常用的API分类如下：

• 文档API: 提供对文档的增删改查操作
• 搜索API: 提供对文档进行某个字段的查询
• 索引API: 提供对索引进行操作，查看索引信息等
• 查看API: 按照更直观的形式返回数据，更适用于控制台请求展示
• 集群API: 对集群进行查看和操作的API

下面简单的一一介绍记录一下。 

文档类API

Index API: 创建并建立索引

PUT twitter/tweet/1{    "user" : "kimchy",    "post_date" : "2009-11-15T14:12:12",    "message" : "trying out Elasticsearch"}

官方文档参考：Index API 。 Get API: 获取文档

curl -XGET 'http://localhost:9200/twitter/tweet/1'

官方文档参考：Get API 。 DELETE API: 删除文档

$ curl -XDELETE 'http://localhost:9200/twitter/tweet/1'

官方文档参考：Delete API 。 UPDATE API: 更新文档

PUT test/type1/1{    "counter" : 1,    "tags" : ["red"]}

官方文档参考：Update API 。 Multi Get API: 一次批量获取文档

curl 'localhost:9200/_mget' -d '{    "docs" : [        {            "_index" : "test",            "_type" : "type",            "_id" : "1"        },        {            "_index" : "test",            "_type" : "type",            "_id" : "2"        }    ]}'

官方文档参考：Multi Get API 。 Bulk API: 批量操作，批量操作中可以执行增删改查

$ curl -s -XPOST localhost:9200/_bulk --data-binary "@requests"; echo{"took":7, "errors": false, "items":[{"index":{"_index":"test","_type":"type1","_id":"1","_version":1,"result":"created","forced_refresh":false}}]}

官方文档参考：Bulk API 。 DELETE By Query API: 根据查询删除

POST twitter/_delete_by_query{  "query": {     "match": {      "message": "some message"    }  }}

官方文档参考：Delete By Query API 。 Update By Query API: 根据查询更新

POST twitter/_update_by_query?conflicts=proceed

官方文档参考：Update By Query API 。 Reindex API：重建索引

POST _reindex{  "source": {    "index": "twitter"  },  "dest": {    "index": "new_twitter"  }}

官方文档参考：Reindex API 。 Term Vectors: 词组分析，只能针对一个文档

curl -XGET 'http://localhost:9200/twitter/tweet/1/_termvectors?pretty=true'

官方文档参考：Term Vectors 。 Multi termvectors API: 多个文档的词组分析

curl 'localhost:9200/_mtermvectors' -d '{   "docs": [      {         "_index": "testidx",         "_type": "test",         "_id": "2",         "term_statistics": true      },      {         "_index": "testidx",         "_type": "test",         "_id": "1",         "fields": [            "text"         ]      }   ]}'

官方文档参考：Multi termvectors API 。 更多关于文档类API请参考：Document APIs 。 

搜索类API

URI Search：url中传参

GET twitter/tweet/_search?q=user:kimchy

官方文档参考：URI Search 。 Request Body搜索接口: 搜索的条件在请求的body中

GET /twitter/tweet/_search{    "query" : {        "term" : { "user" : "kimchy" }    }}

官方文档参考：Request Body Search 。   

• 搜索模版设置接口: 可以设置搜索的模版，模版的功能是可以根据不同的传入参数，进行不同的实际搜索
• 搜索分片查询接口: 查询这个搜索会使用到哪个索引和分片
• Suggest接口: 搜索建议接口，输入一个词，根据某个字段，返回搜索建议。
• 批量搜索接口: 把批量请求放在一个文件中，批量搜索接口读取这个文件，进行搜索查询
• Count接口: 只返回符合搜索的文档个数
• 文档存在接口: 判断是否有符合搜索的文档存在
• 验证接口: 判断某个搜索请求是否合法，不合法返回错误信息
• 解释接口: 使用这个接口能返回某个文档是否符合某个查询，为什么符合等信息
• 抽出器接口: 简单来说，可以用这个接口指定某个文档符合某个搜索，事先未文档建立对应搜索

官方文档参考：Search APIS 。 

索引类API

• 创建索引接口(POST my_index)
• 删除索引接口(DELETE my_index)
• 获取索引信息接口(GET my_index)
• 索引是否存在接口(HEAD my_index)
• 打开/关闭索引接口(my_index/_close, my_index/_open)
• 设置索引映射接口(PUT my_index/_mapping)
• 获取索引映射接口(GET my_index/_mapping)
• 获取字段映射接口(GET my_index/_mapping/field/my_field)
• 类型是否存在接口(HEAD my_index/my_type)
• 删除映射接口(DELTE my_index/_mapping/my_type)
• 索引别名接口(_aliases)
• 更新索引设置接口(PUT my_index/_settings)
• 获取索引设置接口(GET my_index/_settings)
• 分析接口(_analyze): 分析某个字段是如何建立索引的
• 建立索引模版接口(_template): 为索引建立模版，以后新创建的索引都可以按照这个模版进行初始化
• 预热接口(_warmer): 某些查询可以事先预热，这样预热后的数据存放在内存中，增加后续查询效率
• 状态接口(_status): 索引状态
• 批量索引状态接口(_stats): 批量查询索引状态
• 分片信息接口(_segments): 提供分片信息级别的信息
• 索引恢复接口(_recovery): 进行索引恢复操作
• 清除缓存接口(_cache/clear): 清除所有的缓存
• 输出接口(_flush)
• 刷新接口(_refresh)
• 优化接口(_optimize): 对索引进行优化
• 升级接口(_upgrade): 这里的升级指的是把索引升级到lucence的最新格式

官方文档参考：Indices APIS 。 

查看类API

• 查看别名接口(_cat/aliases): 查看索引别名
• 查看分配资源接口(_cat/allocation)
• 查看文档个数接口(_cat/count)
• 查看字段分配情况接口(_cat/fielddata)
• 查看健康状态接口(_cat/health)
• 查看索引信息接口(_cat/indices)
• 查看master信息接口(_cat/master)
• 查看nodes信息接口(_cat/nodes)
• 查看正在挂起的任务接口(_cat/pending_tasks)
• 查看插件接口(_cat/plugins)
• 查看修复状态接口(_cat/recovery)
• 查看线城池接口(_cat/thread_pool)
• 查看分片信息接口(_cat/shards)
• 查看lucence的段信息接口(_cat/segments)

官方文档参考：Cat APIS 。 

集群类API

• 查看集群健康状态接口(_cluster/health)
• 查看集群状况接口(_cluster/state)
• 查看集群统计信息接口(_cluster/stats)
• 查看集群挂起的任务接口(_cluster/pending_tasks)
• 集群重新路由操作(_cluster/reroute)
• 更新集群设置(_cluster/settings)
• 节点状态(_nodes/stats)
• 节点信息(_nodes)
• 节点的热线程(_nodes/hot_threads)
• 关闭节点(/nodes/_master/_shutdown)

官方文档参考：Cluster APIS 。  尽在：https://www.elastic.co/guide/en/elasticsearch/reference/current/index.html

数据中心面临的挑战

1. 被DDOS攻击: 网络瘫痪,大面积影响业务
2. 植入后门发包: 占用带宽资源,消耗成本
3. 运营“黑盒子”: 无法分辨“好人”、“坏人”
4. 监控粒度粗: 无法及时响应并定位事件

 
早期解决方案 

• Cacti 利用SNMP监控交换 机出入口流量
• 交换机推送Sflow流量采样 数据,使用Solarwids监控
• 遇到DDOS时,使用手动 Sniffer抓包分析

 第一期改造后 

 推送Netflow/Sflow 劣势

• 消耗路由器CPU资源
• 100-1000:1采样比,监测粒度粗
• 业务和应用识别依赖端口号,无法识别日新月异 的业务类型 

 
如何用数据驱动IDC运营 

 
NSM架构设计 

 
第二期改造后 

 
10G下的NSM :

 

实际效果展示 

NSM架构解析 

实时协议分析:Bro日志类型 

Flow: 数据格式 

实时安全威胁检测引擎 

Suricata Today 

实时流量 +ELK + VirusTotal 

构建10G+ NSM的几个关键点 
1、抓包网卡   
2、内核优化 
3、驱动与rss 
4、PF-Ring_zc 
5、ntop、nprobe、ndpi 
6、跨数据中心es 
流量抓包与网卡 

ELK部分的关键点 
1、用Logstash Kafka input接收数据
2、数据量大,处理结构复杂时:
      预设Kafka分区 
      开启多个Logstash实例,分别读取Kafka分区数据 
      分别写入不同es节点
3、多集群互联 
跨数据中心es集群 

10G NSM平台样例 

万兆 实时 安全大数据架构 

作者：张磊@Zooboa 

备份

备份数据之前，要创建一个仓库来保存数据，仓库的类型支持共享文件系统、Amazon S3、 HDFS和Azure Cloud。 
 
Elasticsearch的一大特点就是使用简单，api也比较强大，备份也不例外。简单来说，备份分两步：

1. 创建一个仓库
2. 备份指定索引

 
一、创建存储仓库
 
共享文件系统实例如下：

curl -XPUT http://127.0.0.1:9200/_snapshot/EsBackup

{

    "type": "fs", 

    "settings": {

        "location": "/mount/EsDataBackupDir" 

    }

}

上面代码解释：

1. 创建了一个名为EsBackup的存仓库
2. 指定的备份方式为共享文件系统(type: fs)
3. 指定共享存储的具体路径（location参数）

注意：共享存储路径，必须是所有的ES节点都可以访问的，最简单的就是nfs系统，然后每个节点都需要挂载到本地。
 
如上所示，创建存储仓库的时候，除了可以指定location参数以外，我们还可以指点max_snapshot_bytes_per_sec和max_restore_bytes_per_sec参数来限制备份和恢复时的速度，默认值都是20mb/s，假设我们有一个非常快的网络环境,我们可以增大默认值：

curl -XPOST http://127.0.0.1:9200/_snapshot/EsBackup

{

    "type": "fs", 

    "settings": {

        "location": "/mount/EsDataBackupDir" 

        "max_snapshot_bytes_per_sec" : "50mb", 

        "max_restore_bytes_per_sec" : "50mb"

    }

}

注意:这是在第一段代码的基础上来增加配置，第一段代码利用的是PUT请求来创建存储库，这段代码则是利用POST请求来更新已经存在的存储库的settings配置。 
Amazon S3存储库实例如下：

curl -XPUT 'http://localhost:9200/_snapshot/s3-backup' -d '{

    "type": "s3",

    "settings": {

        "bucket": "esbackup",

        "region": "cn-north-1",

        "access_key": "xxooxxooxxoo",

        "secret_key": "xxxxxxxxxooooooooooooyyyyyyyyy"

    }

}'

参数名词解释：

1. Type: 仓库类型
2. Setting: 仓库的额外信息
3. Region: AWS Region
4. Access_key: 访问秘钥
5. Secret_key: 私有访问秘钥
6. Bucket: 存储桶名称

不同的ES版本支持的region参考：https://github.com/elastic/elasticsearch-cloud-aws#aws-cloud-plugin-for-elasticsearch
 
使用上面的命令，创建一个仓库（s3-backup），并且还创建了存储桶（esbackup）,返回{"acknowledged":true} 信息证明创建成功。
 
确认存储桶是否创建成功：curl -XPOST http://localhost:9200/_snapshot/s3-backup/_verify
查看刚创建的存储桶：curl -XGET localhost:9200/_snapshot/s3-backup?pretty
查看所有的存储桶：curl -XGET localhost:9200/_snapshot/_all?pretty
删除一个快照存储桶：curl -XDELETE localhost:9200/_snapshot/s3-backup?pretty
 
二、备份索引
创建好存储仓库之后就可以开始备份了。一个仓库可以包含多个快照（snapshots），快照可以存所有的索引或者部分索引，当然也可以存储一个单独的索引。(要注意的一点就是快照只会备份open状态的索引，close状态的不会备份)
 
 
备份所有索引

curl -XPUT http://127.0.0.1:9200/_snapshot/EsBackup/snapshot_all

上面的代码会将所有正在运行的open状态的索引，备份到EsBacup仓库下一个叫snapshot_all的快照中。上面的api会立刻返回{"accepted":true}，然后备份工作在后台运行。如果你想api同步执行，可以加wait_for_completion 标志：

curl -XPUT http://127.0.0.1:9200/_snapshot/EsBackup/snapshot_all?wait_for_completion=true

上面的方法会在备份完全完成后才返回，如果快照数据量大的话，会花很长时间。

备份部分索引
默认是备份所有open状态的索引，如果你想只备份某些或者某个索引，可以指定indices参数来完成：

curl -XPUT 'http://localhost:9200/_snapshot/EsBackup/snapshot_12' -d '{ "indices": "index_1,index_2" }'

 查看快照信息
查看快照信息，只需要发起GET请求就好：

GET _snapshot/my_backup/snapshot_2

这将返回关于快照snapshot_2的详细信息：

{

   "snapshots": [

      {

         "snapshot": "snapshot_2",

         "indices": [

            ".marvel_2014_28_10",

            "index1",

            "index2"

         ],

         "state": "SUCCESS",

         "start_time": "2014-09-02T13:01:43.115Z",

         "start_time_in_millis": 1409662903115,

         "end_time": "2014-09-02T13:01:43.439Z",

         "end_time_in_millis": 1409662903439,

         "duration_in_millis": 324,

         "failures": [],

         "shards": {

            "total": 10,

            "failed": 0,

            "successful": 10

         }

      }

   ]

}

查看所有快照信息如下：

GET http://127.0.0.1:9200/_snapshot/my_backup/_all

另外还有个一api可以看到更加详细的信息：

GET http://127.0.0.1:9200/_snapshot/my_backup/snapshot_2/_status

更多详细内容可以到官网查看-官方文档地址。
 
删除快照

DELETE _snapshot/my_backup/snapshot_2

重要的是使用API来删除快照,而不是其他一些机制(如手工删除,或使用自动s3清理工具)。因为快照增量,它是可能的,许多快照依靠old seaments。删除API了解最近仍在使用的数据快照,并将只删除未使用的部分。如果你手动文件删除,但是,你有可能严重破坏你的备份,因为你删除数据仍在使用,如果备份正在后台进行，也可以直接删除来取消此次备份。
 
监控快照进展
wait_for_completion标志提供了一个基本形式的监控,但没有足够的快照恢复甚至中等大小的集群。
 
另外两个api会给你更细节的状态的快照。首先你可以执行一个快照ID,就像我们早些时候得到一个特定的快照信息:

GET _snapshot/my_backup/snapshot_3

如果当你调用这个快照还在进步,你会看到信息的时候开始,已经运行多长时间,等等。但是请注意,这个API使用相同的threadpool快照机制。如果你是快照非常大的碎片,之间的时间状态更新可以相当大,因为API是争夺相同的threadpool资源。
 
这时候有个更好的选择_status的api接口：

GET _snapshot/my_backup/snapshot_3/_status

_status API立即返回并给出一个更详细的输出的统计:

{

   "snapshots": [

      {

         "snapshot": "snapshot_3",

         "repository": "my_backup",

         "state": "IN_PROGRESS", 

         "shards_stats": {

            "initializing": 0,

            "started": 1, 

            "finalizing": 0,

            "done": 4,

            "failed": 0,

            "total": 5

         },

         "stats": {

            "number_of_files": 5,

            "processed_files": 5,

            "total_size_in_bytes": 1792,

            "processed_size_in_bytes": 1792,

            "start_time_in_millis": 1409663054859,

            "time_in_millis": 64

         },

         "indices": {

            "index_3": {

               "shards_stats": {

                  "initializing": 0,

                  "started": 0,

                  "finalizing": 0,

                  "done": 5,

                  "failed": 0,

                  "total": 5

               },

               "stats": {

                  "number_of_files": 5,

                  "processed_files": 5,

                  "total_size_in_bytes": 1792,

                  "processed_size_in_bytes": 1792,

                  "start_time_in_millis": 1409663054859,

                  "time_in_millis": 64

               },

               "shards": {

                  "0": {

                     "stage": "DONE",

                     "stats": {

                        "number_of_files": 1,

                        "processed_files": 1,

                        "total_size_in_bytes": 514,

                        "processed_size_in_bytes": 514,

                        "start_time_in_millis": 1409663054862,

                        "time_in_millis": 22

                     }

                  },

                  ...

快照当前运行将显示IN_PROGRESS作为其状态，这个特定的快照有一个碎片仍然转移(其他四个已经完成)。
 
响应包括总体状况的快照,但还深入每和每个实例统计数据。这给你一个令人难以置信的详细视图快照是如何进展的。碎片可以以不同的方式完成:
INITIALIZING： 集群的碎片是检查状态是否可以快照。这通常是非常快。
STARTED：数据被转移到存储库。
FINALIZING：数据传输完成;碎片现在发送快照的元数据。
DONE：快照完成。
FAILED：在快照过程中错误的出处,这碎片/索引/快照无法完成。检查你的日志以获取更多信息。
 

恢复

备份好后，恢复就更容易了，恢复snapshot_1里的全部索引：

POST http://127.0.0.1:9200/_snapshot/my_backup/snapshot_1/_restore

这个api还有额外的参数：

POST http://127.0.0.1:9200/_snapshot/my_backup/snapshot_1/_restore

{

    "indices": "index_1", 

    "rename_pattern": "index_(.+)", 

    "rename_replacement": "restored_index_$1" 

}

参数indices 设置只恢复index_1索引，参数rename_pattern 和rename_replacement用来正则匹配要恢复的索引，并且重命名。和备份一样，api会立刻返回值，然后在后台执行恢复，使用wait_for_completion 标记强制同步执行。
 
另外可以使用下面两个api查看状态：

GET http://127.0.0.1:9200/_recovery/restored_index_3

GET http://127.0.0.1:9200/_recovery/

如果要取消恢复过程（不管是已经恢复完，还是正在恢复），直接删除索引即可：

DELETE http://127.0.0.1:9200/restored_index_3

更多内容参考-官方文档。
 
参考官方文档地址：

1、https://www.elastic.co/guide/en/elasticsearch/guide/current/backing-up-your-cluster.html#_listing_information_about_snapshots
2、https://www.elastic.co/guide/en/elasticsearch/guide/current/_restoring_from_a_snapshot.html

限制内存使用

通常为了让聚合(或者任何需要访问字段值的请求)能够快点，访问fielddata一定会快点， 这就是为什么加载到内存的原因。但是加载太多的数据到内存会导致垃圾回收(gc)缓慢， 因为JVM试着发现堆里面的额外空间，甚至导致OutOfMemory异常。
 
最让你吃惊的是，你会发现Elaticsearch不是只把符合你的查询的值加载到fielddata. 而是把index里的所document都加载到内存，甚至是不同的 _type 的document。
 
逻辑是这样的，如果你在这个查询需要访问documents X，Y和Z， 你可能在下一次查询就需要访问别documents。而一次把所有的值都加载并保存在内存 ， 比每次查询都去扫描倒排索引要更方便。
 
JVM堆是一个有限制的资源需要聪明的使用。有许多现成的机制去限制fielddata对堆内存使用的影响。这些限制非常重要，因为滥用堆将会导致节点的不稳定（多亏缓慢的垃圾回收）或者甚至节点死亡（因为OutOfMemory异常）；但是垃圾回收时间过长，在垃圾回收期间，ES节点的性能就会大打折扣，查询就会非常缓慢，直到最后超时。
 
如何设置堆大小
对于环境变量 $ES_HEAP_SIZE 在设置Elasticsearch堆大小的时候有2个法则可以运用:

• 不超过RAM的50%

Lucene很好的利用了文件系统cache，文件系统cache是由内核管理的。如果没有足够的文件系统cache空间，性能就会变差。

• 不超过32G

如果堆小于32GB，JVM能够使用压缩的指针，这会节省许多内存：每个指针就会使用4字节而不是8字节。 把对内存从32GB增加到34GB将意味着你将有更少的内存可用，因为所有的指针占用了双倍的空间。同样，更大的堆，垃圾回收变得代价更大并且可能导致节点不稳定；这个限制主要是大内存对fielddata影响比较大。

Fielddata大小

参数 indices.fielddata.cache.size 控制有多少堆内存是分配给fielddata。当你执行一个查询需要访问新的字段值的时候，将会把值加载到内存，然后试着把它们加入到fielddata。如果结果的fielddata大小超过指定的大小 ，为了腾出空间，别的值就会被驱逐出去。 默认情况下，这个参数设置的是无限制 — Elasticsearch将永远不会把数据从fielddata里替换出去。 这个默认值是故意选择的：fielddata不是临时的cache。它是一个在内存里为了快速执行必须能被访问的数据结构，而且构建它代价非常昂贵。如果你每个请求都要重新加载数据，性能就会很差。 一个有限的大小强迫数据结构去替换数据。我们将看看什么时候去设置下面的值，首先让我们看一个警告： 【warning】这个设置是一个保护措施，而不是一个内存不足的解决方案  如果你没有足够的内存区保存你的fielddata到内存里，Elasticsearch将会经常性的从磁盘重新加载数据，并且驱逐别的数据区腾出空间。这种数据的驱逐会导致严重的磁盘I/O，并且在内存里产生大量的垃圾，这个会在后面被垃圾回收。 假设你在索引日志，每天使用给一个新的索引。通常情况下你只会对过去1天或者2天的数据感兴趣。即使你把老的索引数据保留着，你也很少查询它们。尽管如此，使用默认的设置， 来自老索引的fielddata也不会被清除出去！fielddata会一直增长直到它触发fielddata circuit breaker --参考断路器 --它将阻止你继续加载fielddata。 在那个时候你被卡住了。即使你仍然能够执行访问老的索引里的fielddata的查询， 你再也不能加载任何新的值了。相反，我们应该把老的值清除出去给新的值腾出空间。 为了防止这种情景，通过在 config/elasticsearch.yml 文件里加上如下的配置给fielddata 设置一个上限：

indices.fielddata.cache.size:  40%

当然可以设置成堆大小的百分比，也可以是一个具体的值，比如 8gb；通过适当的设置这个值，最近被访问的fielddata将被清除出去，给新加载的数据腾出空间。 在网上你可能会看到另外一个设置参数： indices.fielddata.cache.expire 。千万不要使用这个设置！这个设置高版本已经废弃。这个设置告诉Elasticsearch把比过期时间老的数据从fielddata里驱逐出去，而不管这个值是否被用到。这对性能是非常可怕的 。驱逐数据是有代价的，并且这个有目的的高效的安排驱逐数据并没有任何真正的收获。没有任何理由去使用这个设置；我们一点也不能从理论上制造一个假设的有用的情景。现阶段存 在只是为了向后兼容。我们在这个书里提到这个设置是因为这个设置曾经在网络上的各种文章里 被作为一个 ``性能小窍门'' 被推荐过。记住永远不要使用它，就ok！

监控fielddata

监控fielddata使用了多少内存以及是否有数据被驱逐是非常重要的。大量的数据被驱逐会导致严重的资源问题以及不好的性能。 Fielddata使用可以通过下面的方式来监控：

• 对于单个索引使用 {ref}indices-stats.html[indices-stats API]:

GET /_stats/fielddata?fields=*

• 对于单个节点使用 {ref}cluster-nodes-stats.html[nodes-stats API]:

GET /_nodes/stats/indices/fielddata?fields=*

• 或者甚至单个节点单个索引

GET /_nodes/stats/indices/fielddata?level=indices&fields=*

通过设置 ?fields=* 内存使用按照每个字段分解了.

断路器(breaker)

聪明的读者可能已经注意到fielddata大小设置的一个问题。fielddata的大小是在数据被加载之后才校验的。如果一个查询尝试加载到fielddata的数据比可用的内存大会发生什么情况？答案是不客观的：你将会获得一个OutOfMemory异常。
 
Elasticsearch包含了一个 fielddata断路器 ，这个就是设计来处理这种情况的。断路器通过检查涉及的字段（它们的类型，基数，大小等等）来估计查询需要的内存。然后检查加 载需要的fielddata会不会导致总的fielddata大小超过设置的堆的百分比。
 
如果估计的查询大小超过限制，断路器就会触发并且查询会被抛弃返回一个异常。这个发生在数据被加载之前，这就意味着你不会遇到OutOfMemory异常。
 
Elasticsearch拥有一系列的断路器，所有的这些都是用来保证内存限制不会被突破：

indices.breaker.fielddata.limit

这个 fielddata 断路器限制fielddata的大小为堆大小的60%，默认情况下。

indices.breaker.request.limit

这个 request 断路器估算完成查询的其他部分要求的结构的大小，比如创建一个聚集通， 以及限制它们到堆大小的40%，默认情况下。

indices.breaker.total.limit

这个total断路器封装了 request 和 fielddata 断路器去确保默认情况下这2个 使用的总内存不超过堆大小的70%。
 
断路器限制可以通过文件 config/elasticsearch.yml 指定，也可以在集群上动态更新：

PUT /_cluster/settings

{

  "persistent" : {

    "indices.breaker.fielddata.limit" : 40% (1)

  }

}

这个限制设置的是堆的百分比。
 
最好把断路器设置成一个相对保守的值。记住fielddata需要和堆共享 request 断路器， 索引内存缓冲区，过滤器缓存，打开的索引的Lucene数据结构，以及各种各样别的临时数据 结构。所以默认为相对保守的60%。过分乐观的设置可能会导致潜在的OOM异常，从而导致整 个节点挂掉。

从另一方面来说，一个过分保守的值将会简单的返回一个查询异常，这个异常会被应用处理。 异常总比挂掉好。这些异常也会促使你重新评估你的查询：为什么单个的查询需要超过60%的 堆空间。

断路器和Fielddata大小

在 Fielddata大小部分我们谈到了要给fielddata大小增加一个限制去保证老的不使用 的fielddata被驱逐出去。indices.fielddata.cache.size 和 indices.breaker.fielddata.limit 的关系是非常重要的。如果断路器限制比缓冲区大小要小，就会没有数据会被驱逐。为了能够 让它正确的工作，断路器限制必须比缓冲区大小要大。

我们注意到断路器是和总共的堆大小对比查询大小，而不是和真正已经使用的堆内存区比较。 这样做是有一系列技术原因的（比如，堆可能看起来是满的，但是实际上可能正在等待垃圾 回收，这个很难准确的估算）。但是作为终端用户，这意味着设置必须是保守的，因为它是 和整个堆大小比较，而不是空闲的堆比较。

参考：Elasticsearch权威指南笔记 
官网：https://www.elastic.co/guide/en/elasticsearch/guide/current/_limiting_memory_usage.html

基础知识点

在Eleasticsearch中recovery指的就是一个索引的分片分配到另外一个节点的过程；一般在快照恢复、索引副本数变更、节点故障、节点重启时发生。由于master保存整个集群的状态信息，因此可以判断出哪些shard需要做再分配，以及分配到哪个结点，例如:

1. 如果某个shard主分片在，副分片所在结点挂了，那么选择另外一个可用结点，将副分片分配(allocate)上去，然后进行主从分片的复制；
2. 如果某个shard的主分片所在结点挂了，副分片还在，那么将副分片升级为主分片，然后做主从分片复制；
3. 如果某个shard的主副分片所在结点都挂了，则暂时无法恢复，等待持有相关数据的结点重新加入集群后，从该结点上恢复主分片，再选择另外的结点复制副分片。

正常情况下，我们可以通过ES的health的API接口，查看整个集群的健康状态和整个集群数据的完整性：

状态及含义如下：

• green: 所有的shard主副分片都是正常的；
• yellow: 所有shard的主分片都完好，部分副分片没有或者不完整，数据完整性依然完好；
• red: 某些shard的主副分片都没有了，对应的索引数据不完整。

ecovery过程要消耗额外的资源，CPU、内存、结点之间的网络带宽等等。 这些额外的资源消耗，有可能会导致集群的服务性能下降，或者一部分功能暂时不可用。了解一些recovery的过程和相关的配置参数，对于减小recovery带来的资源消耗，加快集群恢复过程都是很有帮助的。

减少集群Full Restart造成的数据来回拷贝

ES集群可能会有整体重启的情况，比如需要升级硬件、升级操作系统或者升级ES大版本。重启所有结点可能带来的一个问题: 某些结点可能先于其他结点加入集群， 先加入集群的结点可能已经可以选举好master，并立即启动了recovery的过程，由于这个时候整个集群数据还不完整，master会指示一些结点之间相互开始复制数据。

那些晚到的结点，一旦发现本地的数据已经被复制到其他结点，则直接删除掉本地“失效”的数据。 当整个集群恢复完毕后，数据分布不均衡，显然是不均衡的，master会触发rebalance过程，将数据在节点之间挪动。

整个过程无谓消耗了大量的网络流量；合理设置recovery相关参数则可以防范这种问题的发生。

gateway.expected_nodes

gateway.expected_master_nodes

gateway.expected_data_nodes

以上三个参数是说集群里一旦有多少个节点就立即开始recovery过程。 不同之处在于，第一个参数指的是master或者data节点都算在内，而后面两个参数则分指master和data node。

在期待的节点数条件满足之前, recovery过程会等待gateway.recover_after_time (默认5分钟) 这么长时间，一旦等待超时，则会根据以下条件判断是否启动:

gateway.recover_after_nodes

gateway.recover_after_master_nodes

gateway.recover_after_data_nodes

举例来说，对于一个有10个data node的集群，如果有以下的设置:

gateway.expected_data_nodes: 10

gateway.recover_after_time: 5m

gateway.recover_after_data_nodes: 8

那么集群5分钟以内10个data node都加入了，或者5分钟以后8个以上的data node加入了，都会立即启动recovery过程。

减少主副本之间的数据复制

如果不是full restart，而是重启单个data node，仍然会造成数据在不同结点之间来回复制。为避免这个问题，可以在重启之前，先关闭集群的shard allocation:

然后在节点重启完成加入集群后，再重新打开:

这样在节点重启完成后，尽量多的从本地直接恢复数据。

但是在ES1.6版本之前，即使做了以上措施，仍然会发现有大量主副本之间的数据拷贝。从表面去看，这点很让人不能理解。 主副本数据完全一致，ES应该直接从副本本地恢复数据就好了，为什么要重新从主片再复制一遍呢？ 原因在于recovery是简单对比主副本的segment file来判断哪些数据一致可以本地恢复，哪些不一致需要远端拷贝的。而不同节点的segment merge是完全独立运行的，可能导致主副本merge的深度不完全一样，从而造成即使文档集完全一样，产生的segment file却不完全一样。

为了解决这个问题，ES1.6版本以后加入了synced flush的新特性。 对于5分钟没有更新过的shard，会自动synced flush一下，实质是为对应的shard加了一个synced flush ID。这样当重启节点的时候，先对比一下shard的synced flush ID，就可以知道两个shard是否完全相同，避免了不必要的segment file拷贝，极大加快了冷索引的恢复速度。

需要注意的是synced flush只对冷索引有效，对于热索引（5分钟内有更新的索引）没有作用。 如果重启的结点包含有热索引，那么还是免不了大量的文件拷贝。因此在重启一个结点之前，最好按照以下步骤执行，recovery几乎可以瞬间完成:

1. 暂停数据写入程序
2. 关闭集群shard allocation
3. 手动执行POST /_flush/synced
4. 重启节点
5. 重新开启集群shard allocation
6. 等待recovery完成，集群health status变成green
7. 重新开启数据写入程序

特大热索引为何恢复慢

对于冷索引，由于数据不再更新，利用synced flush特性，可以快速直接从本地恢复数据。 而对于热索引，特别是shard很大的热索引，除了synced flush派不上用场需要大量跨节点拷贝segment file以外，translog recovery是导致慢的更重要的原因。

从主片恢复数据到副片需要经历3个阶段:

1. 对主片上的segment file做一个快照，然后拷贝到复制片分配到的结点。数据拷贝期间，不会阻塞索引请求，新增索引操作记录到translog里;
2. 对translog做一个快照，此快照包含第一阶段新增的索引请求，然后重放快照里的索引操作。此阶段仍然不阻塞索引请求，新增索引操作记录到translog里;
3. 为了能达到主副片完全同步，阻塞掉新索引请求，然后重放阶段二新增的translog操作。

可见，在recovery完成之前，translog是不能够被清除掉的（禁用掉正常运作期间后台的flush操作）。如果shard比较大，第一阶段耗时很长，会导致此阶段产生的translog很大。重放translog比起简单的文件拷贝耗时要长得多，因此第二阶段的translog耗时也会显著增加。等到第三阶段，需要重放的translog可能会比第二阶段还要多。 而第三阶段是会阻塞新索引写入的，在对写入实时性要求很高的场合，就会非常影响用户体验。 因此，要加快大的热索引恢复速度，最好的方式是遵从上一节提到的方法: 暂停新数据写入，手动sync flush，等待数据恢复完成后，重新开启数据写入，这样可以将数据延迟影响可以降到最低。

万一遇到Recovery慢，想知道进度怎么办呢？ CAT Recovery API可以显示详细的recovery各个阶段的状态。 这个API怎么用就不在这里赘述了，参考: CAT Recovery。

其他Recovery相关的专家级设置

还有其他一些专家级的设置（参考： recovery）可以影响recovery的速度，但提升速度的代价是更多的资源消耗，因此在生产集群上调整这些参数需要结合实际情况谨慎调整，一旦影响应用要立即调整回来。 对于搜索并发量要求高，延迟要求低的场合，默认设置一般就不要去动了。 对于日志实时分析类对于搜索延迟要求不高，但对于数据写入延迟期望比较低的场合，可以适当调大indices.recovery.max_bytes_per_sec，提升recovery速度，减少数据写入被阻塞的时长。

最后要说的一点是ES的版本迭代很快，对于Recovery的机制也在不断的优化中。 其中有一些版本甚至引入了一些bug，比如在ES1.4.x有严重的translog recovery bug，导致大的索引trans log recovery几乎无法完成 （issue #9926） 。因此实际使用中如果遇到问题，最好在Github的issue list里搜索一下，看是否使用的版本有其他人反映同样的问题。

分享阅读参考: https://henduan.com/rCWPD

集群

查看集群状态



curl -s '127.0.0.1:9200/_cluster/health?pretty'



查看集群中所有索引的状态



curl -s '127.0.0.1:9200/_cluster/health?pretty&level=indices'



查看集群中所有索引分片的状态



curl -s '127.0.0.1:9200/_cluster/health?pretty&level=shards' 

节点

查看集群中所有节点的配置信息



curl -s '127.0.0.1:9200/_nodes/?pretty'



查看集群中指定节点的配置信息



curl -s '127.0.0.1:9200/_nodes/{ip|name}?pretty'



查看集群中所有节点的状态信息



curl -s '127.0.0.1:9200/_nodes/stats/?pretty'



查看集群中指定节点的状态信息



curl -s '127.0.0.1:9200/_nodes/{ip|name}/stats/?pretty'



查看集群中所有节点的指定状态信息



curl -s '127.0.0.1:9200/_nodes/stats/{indices|os|process|jvm|thread_pool|fs}?pretty'



查看集群中指定节点的指定状态信息



curl -s '127.0.0.1:9200/_nodes/{ip|name}/stats/{indices|os|process|jvm|thread_pool|fs}?pretty' 

cat

curl -s '127.0.0.1:9200/_cat/?'

索引

查看指定索引的状态信息



curl -s 127.0.0.1:9200/_cat/indices/{index}?v



查看指定索引的分片信息



curl -s 127.0.0.1:9200/_cat/shards/{index}?v



查看指定索引的段信息



curl -s 127.0.0.1:9200/_cat/segments/{index}?v 

原文作者：erica.zhou
原文地址：http://www.z-dig.com/elasticsearch-monitoring.html