es常用运维文档

==============================1.查看是否有UNASSIGNED====================================
查看索引分布在哪些节点上，
查看主分片、
副本分片分布在哪些节点上
GET _cat/shards?v
===========================================================================
2.查看索引健康状态，
查看索引主分片数、副本分片数，
查看文档数，删除文档数，
查看索引大小、主分片大小
GET _cat/indices?v
==============================3.查看unassigned的原因========================================

    GET _cluster/allocation/explain
      {
          "index": "myindex",
          "shard": 0,
          "primary": true
      }
==============================4.给索引设置分片数和副本数========================================

PUT _template/template_http_request_record
{
  "index_patterns": ["db18"],  
  "settings": {  
     "number_of_shards": 16,
     "number_of_replicas": 2 
  }
}

修改某个索引副本数
PUT /testindex/_settings
{
   "number_of_replicas" : 2
}

=============================5.解决es超过10000行无法查询的问题=========================================

PUT db8/_settings
{
  "max_result_window":1000000
}
===============================6.shard移动=======================================

如果发现shard太集中了，可以手动移动shard
POST /_cluster/reroute
{

    "commands" : [ {

        "move" :

            {

              "index" : "db4", "shard" : 0,

              "from_node" : "node-3", "to_node" : "node-1"

            }

        }

    ]

}
============================7.分配stale分片==========================================

在集群的全局状态里保存了分片同步的状态：in-sync copies 和 stale shard
in-sync copies ——指处于同步状态的分片
stale shard     ——指不在同步状态的副本分片
在某些比较极端的情况下只剩下了stale分片，这时候集群会处于red状态，但是并不会将stale分片提升为主分片，因为该数据不是最新，
如果此时不得不将stale分片提升为主分片，需要人工介入：
POST /_cluster/reroute
{

        "commands":[{

            "allocate_stale_primary":{

                "index":"db4",

                "shard":"0",

                "node":"node-1",

                "accept_data_loss":true

            }

        }]

    }
===============================8.分配 empty 分片=======================================

当由于 lucene index 损坏或者磁盘故障导致某个分片的主副本都丢失时，为了能使集群恢复 green 状态，
最后的唯一方法是划分一个空 shard
POST /_cluster/reroute
{

        "commands":[{

            "allocate_empty_primary":{

                "index":"db4",

                "shard":"0",

                "node":"node-1",

                "accept_data_loss":true

            }

        }]

    }
=============================推迟集群重新平衡=========================================
在一个集群中，如果主分片故障了，提升副本分片为主分片尽快恢复丢失的主分片，同时平衡分片在集群的分布，
这本来是个很理想的行为。然而在实践中，立即再均衡却会造成很多的问题，比如网络资源、cpu资源、io资源等
举例：
1.node-1突然在网络中失联了
2.master监测到这个几点离线，找到该几点上的主几点对应的副本几点，并提拔为主节点
3.副本节点提升为主节点后，master开始执行恢复操作来重建缺失的副本节点，然后集群状态恢复绿色
4.由于此时集群还处于非平衡状态，出发分片移动，部分分片在节点间迁移达到平衡（流程完成）
5.如果突然node-1又恢复了，那么必须删除node-1的数据，然后重新恢复集群的分片，然后再度迁移平衡

可以看出这个流程开销是非常大的，为了解决这中闪断问题，es推出了推迟平衡分配。这可以让你的集群在重新分配之前有时间去检测这个节点是否会再次重新加入。
通过修改delayed_timeout，该参数默认是1分钟，该参数可以全局设置也可以索引级别的修改：
PUT /_all/_settings 
{
  "settings": {
    "index.unassigned.node_left.delayed_timeout": "5m" 
  }
}
这里修改表示_all全局修改，5m表示延迟5分钟
注意，该延迟不会阻碍副本提升为主分片，缺失副本重建是会被延迟的
注意，如果节点在超时后在回来，且平衡还没有完成，会发生什么？
 1.es检查该集群磁盘上的分片数据和当前集群活跃的主分片的数据是否一样，如果匹配说明没有新的增删改，
那么master会取消再平衡并恢复该机器磁盘的数据
 2.如果不匹配了，那么恢复会按正常流程继续进行

=============================es集群滚动重启=========================================
1.集群滚动重启：顾名思义就是保持集群可用性的情况下，把集群节点逐一下线。
2.滚动重启与延时分配类似，目的就是避免集群某个节点被检测离线而立即迁移shard再度平衡，造成资源的峰值消耗
3.滚动重启适用场景，es版本升级、或者自身维护等短时间中断，可控中断
4.操作流程：
    1.尽可能停止索引新的数据。
    2.禁止分片分配。这一步会阻止es再度平衡缺失的分片，直到你允许为止。禁止方法：
        PUT /_cluster/settings
        {
                "transient" : {
                        "cluster.routing.allocation.enable" : "none"
                }
        }
    3.curl -XPOST $url/_flush/synced?pretty
    4.关闭单个节点
    5.执行维护/升级
    6.重启节点，然后确认它加入到集群了
    7.用如下命令重启分片分配
        PUT /_cluster/settings
        {
                "transient" : {
                        "cluster.routing.allocation.enable" : "all"
                }
        }    
    分片再度平衡，直到集群状态变成绿色
    8.重复以上操作重启剩余节点
注意：经测试禁止分片分配，新建索引无法分配直到允许分配为止，但是可以往旧索引里做增删该查操作。

==============================集群合并===============================================
两个独立的集群合并需要把数据目录给删了了
例如连个单节点es，现在把他们合并为一个集群，那么其中一个节点的数据目录需要删掉（例如把node目录干掉即可）

==============================shard数不够用============================================

PUT /_cluster/settings
{
  "transient": {
  "cluster": {
  "max_shards_per_node":10000
  }
  }
}

==============================节点踢出================================================
PUT _cluster/settings
{
  "transient" : {
    "cluster.routing.allocation.exclude._name" : "node-3"
  }
}

节点重起后加入集群
PUT _cluster/settings
{
  "transient" : {
    "cluster.routing.allocation.exclude._name" : ""
  }
}

==========================修改为可写==================================================
PUT /*/_settings
{
"index.blocks.read_only_allow_delete": "false"
}

=========================failed to obtain in-memory shard lock==================================
出现未分配分片，可能主分片和副本分片都没有分配，看原因是failed to obtain in-memory shard lock
1. 这样的情况一般是有分片未正常关闭和清理，所以当分片要重新分配回出问题节点的时候没有办法获得分片锁（例如集群磁盘超水位了无法分配）
2.这样的情况一般不会丢失数据，只需要retry_failed重试就可以了
 POST  /_cluster/reroute?retry_failed

=========================_sql查询接口==================================================
POST /_sql?format=txt
{"query":"select * from db11"}

=========================curl登录========================================
curl -u kibana_read:zr#2020 -XGET http://10.110.0.149:9200/_cat/health

=========================求最大值========================

GET player-status-log/_search
{
  "size" : 0,
  "_source" : false,
  "stored_fields" : "_none_",
  "aggregations" : {
    "groupby" : {
      "filters" : {
        "filters" : [
          {
            "match_all" : {
              "boost" : 1.0
            }
          }
        ],
        "other_bucket" : false,
        "other_bucket_key" : "_other_"
      },
      "aggregations" : {
        "max_value" : {
          "min": {
            "field" : "createTime"
          }

      }
    }
  }
}
}

==================================