CLUSTER

CLUSTER 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. MIGRATING подкоманда: Установить слот хэша в состояние перемещения.
2. IMPORTING подкоманда: Установить слот хэша в состояние импорта.
3. STABLE подкоманда: Очистить состояние импорта/перемещения из слота хэша.
4. NODE подкоманда: Связать слот хэша с другим узлом.

Команда с набором подкоманд полезна для запуска и завершения операций решардинга кластера в реальном времени, которые выполняются путем установки слота хэша в состояние перемещения в узле-источнике и состояния импорта в узле-получателе.

Каждая подкоманда документирована ниже. В конце вы найдете описание того, как выполняется решардинг кластера в реальном времени с использованием этой команды и других связанных команд.

CLUSTER SETSLOT <slot> ПЕРЕМЕЩЕНИЕ <destination-node-id>

Эта подкоманда устанавливает слот в состояние перемещения. Для установки слота в это состояние узел, получающий команду, должен быть владельцем слота хэша, в противном случае возвращается ошибка.

Когда слот устанавливается в состояние перемещения, поведение узла меняется следующим образом:

1. Если получена команда об уже существующем ключе, она обрабатывается как обычно.
2. Если получена команда об отсутствующем ключе, узел отправляет перенаправление ASK, прося клиента повторить запрос только для этого конкретного запроса в destination-node. В этом случае клиент не должен обновлять сопоставление слотов хэша с узлами.
3. Если команда содержит несколько ключей, если ни один не существует, поведение такое же, как в пункте 2. Если все существуют, поведение такое же, как в пункте 1. Однако, если существует только частичное количество ключей, команда возвращает ошибку TRYAGAIN, чтобы ключи, которые необходимо перенести в целевой узел, закончили перемещение, чтобы команда с несколькими ключами могла быть выполнена.

CLUSTER SETSLOT <slot> ИМПОРТИРОВАНИЕ <source-node-id>

Эта подкоманда является обратной MIGRATING, и подготавливает узел-получатель к импорту ключей из указанного узла-источника. Команда работает только в том случае, если узел не является уже владельцем указанного слота хэша.

Когда слот устанавливается в состояние импорта, поведение узла меняется следующим образом:

1. Команды, относящиеся к этому слоту хэша, отклоняются, и генерируется перенаправление MOVED, как обычно, но если команда следует за командой ASKING, в этом случае команда выполняется.

Таким образом, когда узел в состоянии перемещения генерирует перенаправление ASK, клиент обращается к целевому узлу, отправляет ASKING, а сразу после этого отправляет команду. Таким образом, команды об отсутствующих ключах в старом узле или ключах, уже перенесенных в целевой узел, выполняются в целевом узле, так что:

1. Новые ключи всегда создаются в целевом узле. Во время миграции слотов хэша нам нужно будет переместить только старые ключи, а не новые.
2. Команды о ключах, которые уже были перенесены, правильно обрабатываются в контексте узла, который является целью миграции, нового владельца слота хэша, для обеспечения согласованности.
3. Без ASKING поведение такое же, как обычно. Это гарантирует, что клиенты с поврежденным сопоставлением слотов хэша не будут писать ошибки в целевой узел, создавая новую версию ключа, который еще не был перенесен.

CLUSTER SETSLOT <slot> УСТОЙЧИВЫЙ

Эта подкоманда просто очищает состояние перемещения/импорта из слота. Она в основном используется для исправления кластера, застрявшего в неправильном состоянии из-за redis-cli --cluster fix. Обычно оба состояния очищаются автоматически в конце миграции с помощью подкоманды SETSLOT ... NODE ..., как объясняется в следующем разделе.

CLUSTER SETSLOT <slot> УЗЕЛ <node-id>

Подкоманда NODE имеет наиболее сложную семантику. Она связывает слот хэша с указанным узлом, однако команда работает только в определенных ситуациях и имеет разные побочные эффекты в зависимости от состояния слота. Ниже приведен набор предварительных условий и побочных эффектов команды:

1. Если текущий владелец слота хэша — узел, получающий команду, но в результате выполнения команды слот будет назначен другому узлу, команда вернет ошибку, если в узле, получающем команду, все еще есть ключи для этого слота хэша.
2. Если слот находится в состоянии перемещения, состояние очищается, когда слот назначается другому узлу.
3. Если слот находился в состоянии импорта в узле, получающем команду, и команда назначает слот этому узлу (что происходит в целевом узле в конце решардинга слота хэша из одного узла в другой), команда имеет следующие побочные эффекты: A) состояние импорта очищается. B) Если эпоха конфигурации узла не является самой большой в кластере, она генерирует новую эпоху и назначает новую эпоху конфигурации себе. Таким образом, ее новое владение слотом хэша будет превосходить любую предыдущую конфигурацию, созданную предыдущими сбоями или миграциями слотов.

Важно отметить, что шаг 3 — единственный случай, когда узел Redis Cluster создаст новую эпоху конфигурации без согласования с другими узлами. Это происходит только при ручном конфигурировании. Однако невозможно, чтобы это создало непостоянную ситуацию, где у двух узлов одинаковая эпоха конфигурации, так как Redis Cluster использует алгоритм разрешения коллизий эпохи конфигурации.

Возврат

Простой строковый ответ: Все подкоманды возвращают OK если команда выполнена успешно. В противном случае возвращается ошибка.

Объяснение решардинга кластера Redis в реальном времени

Команда CLUSTER SETSLOT — важная часть, используемая Redis Cluster для миграции всех ключей, содержащихся в одном слоте хэша, из одного узла в другой. Вот как организуется миграция, с помощью других команд. Будем называть узел, который имеет текущее владение слотом хэша, узлом source, а узел, в который мы хотим мигрировать ключи, узлом 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 важен. Мы хотим, чтобы целевой узел был готов принимать перенаправления ASK, когда узел-источник настроен на отправку перенаправлений.
• Порядок шагов 4 и 5 важен. Целевой узел отвечает за распространение изменения в остальной части кластера. Если узел-источник получает информацию до узла-получателя, и узел-получатель выходит из строя до того, как он устанавливается новым владельцем слота, слот остается без владельца, даже после успешного восстановления.
• Шаг 6, отправка SETSLOT в узлы, не участвующие в решардинге, технически не является необходимым, так как конфигурация в конечном итоге распространится сама. Однако это хорошая идея, чтобы как можно скорее остановить узлы от указания на неправильный узел для перемещенного слота хэша, что приведет к меньшему количеству перенаправлений для поиска нужного узла.