传输前在同一节点上创建的副本

提问者：小点点

传输前在同一节点上创建的副本

我有一个由3个节点组成的Elasticsearch集群。

每天，我都有一个批次输入由3个分片组成的新索引，然后将副本的数量缩放为1。所以在一天结束时，我希望每个节点都携带1个主节点和1个副本。

下图显示了此操作期间每个节点上的磁盘空间使用情况。

在节点0上，在该操作期间一切似乎都很顺利。

然而，节点2在开始的大部分时间都是空闲的，而节点1似乎是在照顾自己的副本加上节点2副本，然后将其转移到节点2（这是我自己的理解，我可能错了）。这对节点1的磁盘使用率造成了很大的压力，几乎达到了磁盘空间使用率的100%。

为什么会出现这种行为？难道不是每个节点都应该在这里照顾自己的副本以平衡负载吗？我可以以某种方式强制它这样做吗？这令人担忧，因为当磁盘达到100%时，整个节点都会像过去一样下降。

更新瓦尔的回答：

你会发现下面的输出

获取_cat/碎片/xxxxxxxxxxxxxxxxxxxxxx_20210617？v

index                           shard prirep state      docs  store ip            node
xxxxxxxxxxxxxxxxxxxxxx_20210617 1     p      STARTED 8925915 13.4gb 172.23.13.255 es-master-0
xxxxxxxxxxxxxxxxxxxxxx_20210617 1     r      STARTED 8925915 13.4gb 172.23.10.76  es-master-2
xxxxxxxxxxxxxxxxxxxxxx_20210617 2     r      STARTED 8920172 13.4gb 172.23.24.221 es-master-1
xxxxxxxxxxxxxxxxxxxxxx_20210617 2     p      STARTED 8920172 13.4gb 172.23.10.76  es-master-2
xxxxxxxxxxxxxxxxxxxxxx_20210617 0     p      STARTED 8923889 13.4gb 172.23.24.221 es-master-1
xxxxxxxxxxxxxxxxxxxxxx_20210617 0     r      STARTED 8923889 13.5gb 172.23.13.255 es-master-0

获取_cat/恢复/xxxxxxxxxxxxxxxxxxxxxx_20210617？v

index                           shard time  type        stage source_host   source_node            target_host   target_node            repository snapshot files files_recovered files_percent files_total bytes       bytes_recovered bytes_percent bytes_total translog_ops translog_ops_recovered translog_ops_percent
xxxxxxxxxxxxxxxxxxxxxx_20210617  0     382ms empty_store done  n/a           n/a                    172.23.24.221 es-master-1            n/a        n/a      0     0               0.0%          0           0           0               0.0%          0           0            0                      100.0%
xxxxxxxxxxxxxxxxxxxxxx_20210617  0     21.9m peer        done  172.23.24.221 es-master-1            172.23.13.255 es-master-0            n/a        n/a      188   188             100.0%        188         14467579393 14467579393     100.0%        14467579393 55835        55835                  100.0%
xxxxxxxxxxxxxxxxxxxxxx_20210617  1     395ms empty_store done  n/a           n/a                    172.23.13.255 es-master-0            n/a        n/a      0     0               0.0%          0           0           0               0.0%          0           0            0                      100.0%
xxxxxxxxxxxxxxxxxxxxxx_20210617  1     9m    peer        done  172.23.13.255 es-master-0            172.23.10.76  es-master-2            n/a        n/a      188   188             100.0%        188         14486949488 14486949488     100.0%        14486949488 0            0                      100.0%
xxxxxxxxxxxxxxxxxxxxxx_20210617  2     17.8m peer        done  172.23.10.76  es-master-2            172.23.24.221 es-master-1            n/a        n/a      134   134             100.0%        134         14470475298 14470475298     100.0%        14470475298 1894         1894                   100.0%
xxxxxxxxxxxxxxxxxxxxxx_20210617  2     409ms empty_store done  n/a           n/a                    172.23.10.76  es-master-2            n/a        n/a      0     0               0.0%          0           0           0               0.0%          0           0            0                      100.0%

共1个答案

匿名用户

首先，如果您有3个节点，并且您的索引有3个主节点，每个主节点有1个副本，那么绝对不能保证每个节点都将包含一个主节点和一个副本。

你唯一的保证是：

分片计数将在节点上平衡，并且
主节点及其副本永远不会登陆同一节点。

话虽如此，一个节点完全有可能获得两个主节点，另外两个副本，第三个节点获得一个主节点和一个副本。

看看图表，我认为你的情况是

节点2获得两个初选和
节点0获得一个主节点

然后，当您添加副本时：

节点0（只有一个主节点）获得一个副本（曲线不那么陡峭）
节点1（到目前为止什么都没有）得到两个副本（曲线变得更陡峭）
节点2保持不变，因为它已经有两个初选

稍后，当节点1的磁盘接近饱和时，一个分片从它重新定位到节点2（在23:16曲线开始增加）。

最终的情况似乎是：

具有一个主节点和一个副本的节点0
只有一个副本的节点1
具有两个主节点和一个副本的节点2

我认为用以下两个命令确认这一点会很好：

# you can see where each shard is located now
GET _cat/shards/tax*?v

# you can see which shards went from which node to which node
GET _cat/recovery/indexname*?v