集群 SETSLOT

语法
CLUSTER SETSLOT slot <IMPORTING node-id | MIGRATING node-id |
  NODE node-id | STABLE>
从以下位置开始可用：
3.0.0
时间复杂度：
O（1）
ACL 类别：
@admin, @slow, @dangerous,

CLUSTER SETSLOT负责以不同的方式更改接收节点中哈希槽的状态。它可以，具体取决于使用的子命令：

  1. MIGRATINGsubcommand：设置处于 migrating 状态的哈希槽。
  2. IMPORTINGsubcommand：设置一个 Importing 状态的 hash slot。
  3. STABLEsubcommand： 从 hash slot 中清除所有导入 / 迁移状态。
  4. NODEsubcommand：将 hash slot 绑定到不同的节点。

该命令及其子命令集可用于启动和结束集群实时重新分片作，这些作是通过在源节点中将哈希槽设置为迁移状态并在目标节点中导入状态来完成的。

每个子命令都记录在下面。在最后，您将找到 如何使用此命令和其他相关命令执行实时重新分片。

集群 SETSLOT<slot>迁移<destination-node-id>

此子命令将槽设置为迁移状态。为了设置插槽 在此状态下，接收命令的节点必须是 hash slot owner， 否则返回错误。

当槽设置为正在迁移状态时，节点会更改 以下方式：

  1. 如果收到有关现有密钥的命令，则照常处理该命令。
  2. 如果收到有关不存在的密钥的命令，则ASK重定向由节点发出，要求客户端仅重试该特定查询destination-node.在这种情况下，客户端不应更新其哈希槽到节点的映射。
  3. 如果命令包含多个键，如果不存在，则行为与点 2 相同，如果全部存在，则与点 1 相同，但是如果仅存在部分键，则命令会发出一个TRYAGAIN错误，以便将感兴趣的密钥完成迁移到目标节点，以便可以执行 multi keys 命令。

集群 SETSLOT<slot>进口<source-node-id>

此子命令与MIGRATING，并准备目标 node 从指定的源节点导入密钥。该命令仅在以下情况下有效 该节点尚未成为指定哈希槽的所有者。

当插槽设置为导入状态时，节点将按以下方式更改行为：

  1. 有关此哈希槽的命令被拒绝，并且MOVED重定向会像往常一样生成，但在这种情况下，命令遵循ASKINGcommand，在本例中执行命令。

这样，当处于迁移状态的节点生成ASK重定向，客户端联系目标节点，发送ASKING，然后立即发送命令。这样，有关旧节点中不存在的键或已迁移到目标节点的键的命令将在目标节点中执行，以便：

  1. 始终在目标节点中创建新键。在哈希槽迁移期间，我们只需要移动旧键，而不必移动新键。
  2. 有关已迁移键的命令将在作为迁移目标的节点（新的哈希槽所有者）的上下文中正确处理，以保证一致性。
  3. 没有ASKING行为与往常相同。这可保证哈希槽映射损坏的客户端不会在目标节点中写入 for error，从而创建尚未迁移的密钥的新版本。

集群 SETSLOT<slot>稳定

此子命令只是从 slot 中清除 migrating / importing 状态。是的 主要用于修复卡错状态的集群redis-cli --cluster fix. 通常，这两种状态会在迁移结束时自动清除 使用SETSLOT ... NODE ...子命令，如下一节所述。

集群 SETSLOT<slot>节点<node-id>

这NODEsubcommand 是语义最复杂的一个。它 将哈希槽与指定的节点相关联，但该命令有效 仅在特定情况下，并且具有不同的副作用，具体取决于 slot 状态。以下是 命令：

  1. 如果当前哈希槽所有者是接收命令的节点，但为了命令的效果，该槽将被分配给其他节点，则如果接收命令的节点中仍有该哈希槽的键，则该命令将返回错误。
  2. 如果槽处于 migrating 状态，则在将槽分配给另一个节点时，该状态将被清除。
  3. 如果 slot 在接收命令的节点中处于 importing状态，并且命令将 slot 分配给此节点（这发生在 hash slot 从一个节点重新分片到另一个节点结束时的目标节点中），则该命令具有以下副作用：A） 导入状态被清除。B） 如果节点配置 epoch 不是集群中最大的，它会生成一个新的 node 并将新的配置 epoch 分配给自身。这样，其新的哈希槽所有权将胜过由以前的故障转移或槽迁移创建的任何过去配置。

请务必注意，步骤 3 是 Redis 集群节点在没有其他节点同意的情况下创建新的配置 epoch 的唯一时间。这仅在作手动配置时发生。但是，这不可能创建两个节点具有相同配置 epoch 的非瞬态设置，因为 Redis Cluster 使用配置 epoch 冲突解决算法。

Redis 集群实时重新分片说明

这CLUSTER SETSLOT命令是 Redis Cluster 使用的一个重要部分，用于将一个哈希槽中包含的所有键从一个节点迁移到另一个节点。这就是在其他命令的帮助下编排迁移的方式。我们将具有哈希槽当前所有权的节点称为sourcenode，以及我们要将destination节点。

  1. 使用 将目标节点插槽设置为导入状态CLUSTER SETSLOT <slot> IMPORTING <source-node-id>.
  2. 使用 将源节点插槽设置为迁移状态CLUSTER SETSLOT <slot> MIGRATING <destination-node-id>.
  3. 使用CLUSTER GETKEYSINSLOT命令，然后使用MIGRATE命令。
  4. 发送CLUSTER SETSLOT <slot> NODE <destination-node-id>拖动到目标节点。
  5. 发送CLUSTER SETSLOT <slot> NODE <destination-node-id>拖动到源节点。
  6. 发送CLUSTER SETSLOT <slot> NODE <destination-node-id>添加到其他主节点（可选）。

笔记：

  • 步骤 1 和 2 的顺序很重要。我们希望目标节点准备好接受ASKredirection。
  • 步骤 4 和 5 的顺序很重要。 目标节点负责将更改传播到集群的其余部分。 如果源节点在目标节点之前收到通知，并且目标节点在设置为新的槽所有者之前崩溃，则即使在成功故障转移后，该槽也没有所有者。
  • 第 6 步，发送SETSLOT到不涉及重新分片的节点，在技术上不是必需的，因为配置最终会传播自身。 但是，这样做是一个好主意，以便阻止节点尽快指向移动的哈希槽的错误节点，从而减少查找正确节点的重定向。

RESP2/RESP3 回复

简单的字符串回复：所有子命令都返回OK如果命令成功。否则，将返回错误。
为本页评分
返回顶部 ↑