Elastic：Elasticsearch 的分片管理策略_elastico的交易分片策略

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

另一个用例是从活动集群中停用节点。 这种情况下的主要挑战之一是在不导致群集停机或重启的情况下停用节点。 幸运的是，Elasticsearch 提供了一个选项，可以在不丢失数据或不会造成停机的情况下，优雅地删除/停用节点。 让我们看看如何实现它：

PUT _cluster/settings
{
  "transient": {
    "cluster.routing.allocation.exclude._ip": "IP of the node"
  }
}

上面的 API 使集群停止分配任何东西到指定节点并排除它。 同时，来自该节点的数据将被移植到非排除节点。 数据传输将在后台进行，完成后将导致从群集中完全删除该节点。

停用某个节点时，其他节点中可用的磁盘空间应大于要传输的数据大小。 否则，群集状态可能会变为红色或黄色，这可能会导致停机。

拥有其他选项来标识要停用的节点通常会很有帮助。 在上面的示例中，我们用节点的 “ip” 标识了该节点。 我们还可以使用集群中唯一的 “node ID” 和 “node name” 进行相同的操作。

按节点ID排除

PUT _cluster/settings
{
  "transient": {
    "cluster.routing.allocation.exclude._id": "unique id of the node"
  }
}

按名称排除节点

PUT _cluster/settings
{
  "transient": {
    "cluster.routing.allocation.exclude._name": "name of the node"
  }
}

我们如何查看节点的停用是否结束？ 为此，我们有两个规定：

方法一

我们使用如下的方法：

GET _cluster/health?pretty

显示的结果是：

{
  "cluster_name" : "elasticsearch",
  "status" : "yellow",
  "timed_out" : false,
  "number_of_nodes" : 1,
  "number_of_data_nodes" : 1,
  "active_primary_shards" : 26,
  "active_shards" : 26,
  "relocating_shards" : 0,
  "initializing_shards" : 0,
  "unassigned_shards" : 19,
  "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" : 57.77777777777777
}

在上面 relocating_shards 显示的数值为0，表明目前没有 shard 被重新转移。

方法二

使用以下 API 检查的专有的节点的状态：

GET _cat/nodes?v

通过上面的 API 我们得到 node 的名字:

ip        heap.percent ram.percent cpu load_1m load_5m load_15m node.role master name
127.0.0.1           42          50   2    1.94                  dilm      *      liuxg-2.local

然后使用如下的 API:

GET _nodes/liuxg-2.local/stats/indices

在上面的  liuxg-2.local  为我们的 node 的名字。显示的结果为：

  "nodes" : {
    "Zs0Uy-9mTDOifm5Ef8U6FA" : {
      "timestamp" : 1581585326681,
      "name" : "liuxg-2.local",
      "transport_address" : "127.0.0.1:9300",
      "host" : "127.0.0.1",
      "ip" : "127.0.0.1:9300",
      "roles" : [
        "ingest",
        "master",
        "data",
        "ml"
      ],
      "attributes" : {
        "ml.machine_memory" : "34359738368",
        "xpack.installed" : "true",
        "ml.max_open_jobs" : "20"
      },
      "indices" : {
        "docs" : {
          "count" : 0,
          "deleted" : 8
        },
   ...

如果上述的 indices.docs.count 的值为 0，就表示转移已经完成。

重命名索引

另一个用例是重命名索引。 可以根据使用情况以多种方式完成此操作。

Aliasing

如果我们希望在不丢失任何数据的情况下重命名索引，则最常用的方法是别名。

例如，我们想将索引 “testindex” 重命名为 “testindex-1”。 我们可以为索引 “testindex” 提供别名 “testindex-1”，以便所有引用 “testindex-1” 的请求现在都将路由到 “testindex”。 可以按照以下步骤完成：

POST _aliases
{
  "actions": [
    {
      "add": {
        "index": "testindex",
        "alias": "testindex-1"
      }
    }
  ]
}

这种方法使我们可以在停机时间为零的情况下重命名索引。

Reindex API

有时，别名并不是重命名的最佳选择。 在这种情况下，我们剩下称为重新索引的选项。 它将所有文档从目标索引重新索引到目标索引。 为了有效地做到这一点，需要检查两件事：

• 机器上是否还有足够的空间。
• 目标索引是否存在正确的映射。

如果满足以上两个条件，我们可以使用如下所示的 reindex API：

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上软件测试知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

需要这份系统化的资料的朋友，可以戳这里获取

47)]

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上软件测试知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

需要这份系统化的资料的朋友，可以戳这里获取