Два способа собрать Valkey из нескольких узлов: кластер и Sentinel

Кто знает, куда слать команду

Вся разница выводится отсюда. В кластере карту знает каждый узел данных: придёте не по адресу — он не откажет, а назовёт нужный. Под Sentinel узел данных про топологию не знает вовсе, и спросить надо отдельную службу.

узел кластера:      SET foo 1  ->  MOVED 12182 127.0.0.1:48711
узел под sentinel:  CLUSTER INFO -> ERR This instance has cluster support disabled
sentinel:           SENTINEL get-master-addr-by-name cache -> 127.0.0.1:41979

Ключ, слот, узел

Адресация в два шага. Первый — арифметика: HASH_SLOT = CRC16(key) mod 16384. Второй — состояние кластера: слот кому-то принадлежит. Поэтому переезд данных не меняет ни одного ключа, он меняет владельца слота.

Фигурные скобки в имени ключа — не украшение: хешируется только то, что внутри них. {u}:a и {u}:b попадают в один слот и оказываются на одном узле.

Что ломается в кластере

Отказ не про «две записи сразу», а про два разных слота: команда выполняется целиком на одном узле. Набор ключей, которые придётся трогать одной командой, в кластере решается до первой записи.

Нумерованные базы: тут решает версия

Проверить «в кластере база ровно одна» проще всего опытом — и он подтверждает это ответом SELECT 1 → ERR DB index is out of range. Ответ настоящий, вывод неверный: это правило Redis и Valkey до 9.0.

кластер А: cluster-databases 1     SELECT 1 -> ERR DB index is out of range
кластер Б: cluster-databases 16    SELECT 1 -> OK

Два кластера, одна строка разницы. Номер базы при этом в адресацию не входит: один и тот же ключ в базах 0 и 1 держит разные значения, но слот у него один и тот же — 12182.

Чего базы в кластере НЕ дают: SWAPDB остаётся запрещён, а DBSIZE, SCAN и FLUSHDB видят только часть базы — ту, что лежит на узле, куда пришла команда. Три ключа в одной базе разошлись по трём узлам, и каждый узел насчитал один.

Отказ мастера

Сравнивать длительности бессмысленно — они настраиваются. Сравнивать надо, что получил клиент.

в кластере, опрашивая живой узел:
  t= 0.00  MOVED 12182 127.0.0.1:36355     (старый адрес слота)
  t= 3.39  CLUSTERDOWN The cluster is down (слот сейчас не покрыт)
  t= 3.49  MOVED 12182 127.0.0.1:39129     (новый адрес)

под sentinel, опрашивая старый адрес:
  t= 0.00  Could not connect to Valkey at 127.0.0.1:44393
  t= 2.30  sentinel называет мастером 127.0.0.1:41979

В кластере клиент всё время получал осмысленные ответы от живого узла. Под sentinel нового адреса ему не сказал никто — он обязан спросить сам.

Самое опасное место

Старый мастер вернулся — и поднялся мастером: он таким себя помнит.

  t= 0.06  роль master, запись -> OK
  t=10.10  роль slave, запись -> READONLY You can't write against a read only replica.

  сразу после перевода: GET who   old
  после синхронизации:  GET who   (её нет)

Десять секунд записи принимались, потом исчезли при синхронизации с настоящим мастером. Ошибки клиент не видел. В кластере такого окна нет: вернувшийся узел сразу отдаёт MOVED на новый адрес.

Отсюда правило из спецификации клиента Sentinel: адрес надо переспрашивать при каждом переподключении, а не один раз при старте.

Что выбирать

не хватает памяти или пропускной способности одного узла → кластер
данные влезают в узел, нужна отказоустойчивость          → Sentinel
код опирается на MSET по произвольным ключам             → Sentinel проще
нужны нумерованные базы                                  → Valkey 9+: оба
нужен SWAPDB                                             → только Sentinel
клиент не умеет протокол кластера                        → кластер не возьмёте
клиент не умеет sentinel                                 → Sentinel не возьмёте

Две последние строки важны: оба режима требуют своей поддержки в клиенте, и умения эти независимы. Обычный клиент, не знающий про кластер, получив MOVED, просто отдаст текст ошибки приложению — карту слотов он не ведёт.

Чем измерено

Всё снято на Valkey 9.1.2, собранном из исходников, на одном хосте. Скрипты и записи прогонов — bench/valkey-cluster/.

Секунды не переносятся: узел считается упавшим через секунду молчания вместо тридцати по умолчанию. А дословные ответы сервера переносятся полностью — это поведение, а не измерение.

И ещё одно, что переносится хуже всего: версия. Нумерованные базы в кластере появились в 9.0, атомарный перенос слотов — в Valkey 9.0 и в Redis 8.4. Правила про кластер, взятые из знаний о Redis, надо помечать версией.

Один вопрос, на который два режима отвечают по-разному

Почти все сравнения кластера и Sentinel начинаются с таблицы «шардирование есть / шардирования нет». Это правда, но это следствие, а не причина, и из такой таблицы не выводится ни одно из практических отличий — ни почему перестаёт работать MSET, ни почему клиенту нужна особая библиотека, ни откуда берётся окно, в котором записи уходят в никуда.

Различают эти режимы четыре вещи разом, и путать их дорого:

РАСКЛАДКА ДАННЫХ   кластер шардирует по 16 384 слотам; Sentinel — нет,
                   данные целиком на одном мастере
КТО РЕШАЕТ         кластер — сами узлы, большинством мастеров;
                   Sentinel — отдельная служба, большинством наблюдателей
КТО АДРЕСУЕТ       кластер — узел данных, обычной командой;
                   Sentinel — та же служба, отдельной командой
ЧТО УМЕЕТ КЛИЕНТ   для каждого режима нужна своя поддержка в библиотеке,
                   и умения эти независимы

Из первой строки растёт набор доступных команд, из второй — поведение при отказе, из третьей — протокол подключения, из четвёртой — можно ли вообще взять этот режим с вашей библиотекой. Ниже они разобраны по очереди, и начать стоит с третьей: она короче всех объясняет, почему два режима вообще путают.

Итак, у клиента есть вопрос: куда отправить эту команду. Два режима отвечают на него разными сторонами.

Дальше — следствия, и каждое проверено прогоном, а не выведено рассуждением. Выводить их рассуждением, кстати, и не получится: раскладка данных и версия добавляют своё, и один только вопрос «кто отвечает адресом» всех отличий не объясняет.

Как ключ превращается в адрес

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

Второй шаг — из слота в узел, и вот он уже не арифметика, а состояние кластера: слоты кому-то принадлежат, и принадлежность меняется. Отсюда важное свойство: переезд данных между узлами не меняет ни одного ключа. Меняется владелец слота, а формула остаётся той же.

Проверяется это одной командой, отправленной по очереди всем шести узлам. Флага -c у клиента нет — он нарочно «глупый» и никуда не переходит, чтобы было видно, что именно сказал сервер:

1. КЛАСТЕР ОТВЕЧАЕТ НЕ ДАННЫМИ, А АДРЕСОМ
----------------------------------------------------------------------
  CLUSTER KEYSLOT foo                         12182

  узел 44997 (мастер): SET foo 1              MOVED 12182 127.0.0.1:48711
  узел 53953 (мастер): SET foo 1              MOVED 12182 127.0.0.1:48711
  узел 48711 (мастер): SET foo 1              OK
  узел 39529 (реплика): SET foo 1             MOVED 12182 127.0.0.1:48711
  узел 54583 (реплика): SET foo 1             MOVED 12182 127.0.0.1:48711
  узел 51665 (реплика): SET foo 1             MOVED 12182 127.0.0.1:48711

MOVED — это ошибка протокола, ошибка перенаправления: команда не выполнена, и узел вернул не данные, а адрес того, кто её выполнит. Сбоем приложения она при этом обычно не становится — клиент кластера чинит на ней свою карту слотов и повторяет команду по названному адресу. Заметьте, что ответили одинаково и мастера, и реплики: карту знают все.

Разница между «не выполнена и перенаправлена» и «не выполнена и неизвестно что» здесь принципиальна, и её стоит держать отдельно от повтора после сетевого сбоя. На MOVED повтор безопасен: узел точно ничего не сделал. А если оборвалась связь после отправки, клиент не знает, выполнилась команда или нет, — и повтор там уже вопрос идемпотентности, а не маршрутизации.

Что при этом делает настоящий клиент

Предыдущий блок показывает протокол, но не показывает поведение: настоящая библиотека MOVED прячет. Что она делает на самом деле, считают сами узлы — по своему счётчику обработанных команд, с контрольным окном той же длины вхолостую (узлы кластера всё время говорят друг с другом, и без контроля клиентское от фонового не отличить).

Клиенту дали один адрес из шести, и не тот, где лежит ключ:

  узел                    вхолостую  с клиентом  что пришло за второе окно
  51665 (адрес клиенту)           2           7  client|setinfo×2 cluster|slots×1 hello×1 set×1

Один поход за картой слотов (cluster|slots) — и дальше запись ушла прямо нужному узлу. Отсюда то, что обычно имеют в виду под «кластер сам разбирается»: знать все узлы клиенту не нужно, достаточно одного живого; посредника между клиентом и данными нет вообще.

Под sentinel порядок обратный, и это видно в том же замере: сначала вопрос службе, потом команда данным. Узел данных в поиске самого себя не участвовал и не мог бы:

2. В РЕЖИМЕ SENTINEL УЗЕЛ ДАННЫХ ПРО ТОПОЛОГИЮ НЕ ЗНАЕТ НИЧЕГО
----------------------------------------------------------------------
  узел данных 43471: CLUSTER INFO             ERR This instance has cluster support disabled
  узел данных 43471: роль                     master

Здесь стоит сразу сузить формулировку, которая напрашивается и оказывается шире измеренного. «Узел про топологию не знает ничего» — неверно: свою пару репликации он знает вполне.

19. ЧТО УЗЕЛ ПОД SENTINEL ВСЁ-ТАКИ ЗНАЕТ О ТОПОЛОГИИ
----------------------------------------------------------------------
  мастер про себя (INFO replication):
    role:master
    connected_slaves:2
    slave0:ip=127.0.0.1,port=45047,state=online,offset=154,lag=0,type=replica
    slave1:ip=127.0.0.1,port=52369,state=online,offset=154,lag=0,type=replica

  реплика про себя:
    role:slave
    master_host:127.0.0.1
    master_port:34351
    master_link_status:up

Чего он не знает — так это авторитетного ответа на вопрос «кто мастер этой службы сейчас». Своё мнение у него есть, и в момент переключения оно бывает устаревшим; ровно это и произойдёт в разделе про вернувшийся адрес.

Спецификация клиента Sentinel описывает обязательную последовательность прямым текстом — и в ней три шага, а не один:

Третий шаг — проверка ROLE — выглядит перестраховкой ровно до раздела про вернувшийся адрес. Там видно, от чего именно она страхует.

И чего она не даёт: это проверка, а не доказательство. Если устаревшим окажется и ответ службы, и мнение самого узла — а именно такая пара и получается в первые секунды после переключения, — ROLE ответит master, и клиент примет старый адрес за верный. Спецификация этот случай называет редким и полагается на то, что sentinel позже разорвёт такие соединения; но согласованности она не обещает.

Что в кластере ломается из привычного

Отсюда и растёт список команд, которые в кластере перестают работать. Список не произвольный: команда выполняется целиком на одном узле, значит команда, которой нужны два ключа из разных слотов, не может быть выполнена нигде.

5. ОДНА КОМАНДА НА ДВА КЛЮЧА: ГДЕ ПРОХОДИТ ГРАНИЦА
----------------------------------------------------------------------
  CLUSTER KEYSLOT foo                       12182
  CLUSTER KEYSLOT bar                       5061
  CLUSTER KEYSLOT {u}:a                     11826
  CLUSTER KEYSLOT {u}:b                     11826

  MSET foo 1 bar 2                          
    в кластере                              CROSSSLOT Keys in request don't hash to the same slot
    под sentinel                            OK

  MSET {u}:a 1 {u}:b 2                      
    в кластере                              MOVED 11826 127.0.0.1:42549
    под sentinel                            OK

Отказ не про «две записи сразу», а про два разных слота: те же две записи с общей фигурной скобкой проходят. Скобки — не украшение имени:

Практическое следствие дороже всего обходится задним числом: в кластере набор ключей, которые понадобится трогать одной командой, решается до первой записи. Под sentinel такого решения принимать не надо вовсе.

Второй пункт списка — нумерованные базы, и вот тут расхожее знание даёт неверный ответ. Заблуждение поучительное, поэтому разобрано оно не строчкой, а отдельным разделом ниже.

Нумерованные базы: здесь ответ зависит от версии Valkey

Проверить «в кластере база одна» проще всего одним опытом:

6. НУМЕРОВАННЫЕ БАЗЫ: В ОДНОМ РЕЖИМЕ ЕСТЬ, В ДРУГОМ НЕТ
----------------------------------------------------------------------
  SELECT 1                                  
    в кластере                              ERR DB index is out of range
    под sentinel                            OK

  SWAPDB 0 1                                
    в кластере                              ERR SWAPDB is not allowed in cluster mode
    под sentinel                            OK

— и делала из него вывод «в кластере база ровно одна». Ответ сервера настоящий, вывод неверный. Правильный вывод из одного этого опыта только такой: в ЭТОМ кластере база настроена одна. Отличить одно от другого можно было лишь вторым опытом, и его не было.

Потому что в Valkey 9.0 нумерованные базы в кластере появились:

Число баз задаёт отдельная настройка, cluster-databases, и по умолчанию она равна единице — поэтому кластер, поднятый обычным способом, ведёт себя по-старому. Два кластера, отличающиеся ровно этой строкой:

14. СКОЛЬКО БАЗ В КЛАСТЕРЕ, РЕШАЕТ НАСТРОЙКА, А НЕ РЕЖИМ
----------------------------------------------------------------------
  кластер А: cluster-databases            1
  кластер Б: cluster-databases            16

  кластер А (по умолчанию): SELECT 0      OK
  кластер А (по умолчанию): SELECT 1      ERR DB index is out of range
  кластер А (по умолчанию): SELECT 15     ERR DB index is out of range
  кластер А (по умолчанию): SELECT 16     ERR DB index is out of range

  кластер Б (16 баз): SELECT 0            OK
  кластер Б (16 баз): SELECT 1            OK
  кластер Б (16 баз): SELECT 15           OK
  кластер Б (16 баз): SELECT 16           ERR DB index is out of range

Одна строка конфига — и SELECT 1 из отказа превращается в OK. Настройка неизменяемая (IMMUTABLE_CONFIG в src/config.c), то есть выбирается при запуске узла и на лету не меняется.

Номер базы не участвует в адресации

Это второй вопрос, и он интереснее первого: не ломает ли новая возможность двухшаговую адресацию, на которой держится весь кластер. Не ломает.

15. НОМЕР БАЗЫ НЕ УЧАСТВУЕТ В ВЫЧИСЛЕНИИ СЛОТА
----------------------------------------------------------------------
  узел-владелец слота ключа foo           127.0.0.1:51799

  в базе 0: SET foo db0                   OK
  в базе 1: SET foo db1                   OK

  в базе 0: GET foo                       db0
  в базе 1: GET foo                       db1

  в базе 0: CLUSTER KEYSLOT foo           12182
  в базе 1: CLUSTER KEYSLOT foo           12182

Один ключ, два значения, один слот. База добавляется третьим измерением уже внутри узла, а раскладка данных по узлам от неё не зависит ни на ключ.

И чего это НЕ даёт

Из «базы появились» так же легко сделать обратный миф — будто в кластере они теперь как в одиночном узле. Нет:

16. ЧТО НЕ ИЗМЕНИЛОСЬ: ЗАПРЕТЫ И ГРАНИЦА ВИДИМОСТИ
----------------------------------------------------------------------
  SWAPDB 0 1                              ERR SWAPDB is not allowed in cluster mode

  в базе 1 записаны три ключа, разошедшиеся по трём узлам:
      CLUSTER KEYSLOT foo                 12182
      CLUSTER KEYSLOT bar                 5061
      CLUSTER KEYSLOT user:1              10778

  что отвечает DBSIZE в базе 1 на каждом узле:
      узел 37191                          1
      узел 50991                          1
      узел 51799                          1

  SCAN в базе 1 на узле-владельце         0 foo
  SCAN в базе 1 на узле 37191             0 bar

SWAPDB как был запрещён, так и остался. А DBSIZE и SCAN считают не базу целиком, а её часть на том узле, куда пришла команда: три ключа записаны в одну базу, разошлись по трём узлам, и ни один узел не видит всех трёх. То же касается FLUSHDB. Документация называет это прямо:

Оттуда же — про то, за чем нумерованные базы брать не стоит:

Итог: нумерованная база в кластере — это пространство имён, а не отдельное хранилище. Разнести по ним окружения можно; ждать от них изоляции или общего на кластер представления о содержимом — нельзя.

Отсюда правило, которое стоит унести из статьи целиком

Ошибка здесь не в невнимательности. Она в том, что знание про кластер берётся оттуда, откуда его берут все: из общей памяти про Redis Cluster, где база действительно одна. На Valkey 9 это правило перестало быть верным, а выглядит по-прежнему верным — потому что значение по умолчанию его подтверждает.

Правило простое: любое утверждение про кластер, унаследованное из знаний о Redis, надо помечать версией — или проверять. Проверка здесь стоила одной строки конфига и двух минут.

Отказ мастера: одно событие, два разных клиентских опыта

Здесь и лежит главное практическое отличие, и оно не в секундах. Сравнивать длительности бессмысленно: обе настраиваются, и в замере обе намеренно укорочены, чтобы прогон укладывался в минуты. Сравнивать надо текст, который получает клиент.

В кластере опрашивался живой узел — не тот, что упал:

8. ОТКАЗ МАСТЕРА В КЛАСТЕРЕ ГЛАЗАМИ КЛИЕНТА
----------------------------------------------------------------------
  слот ключа принадлежит        127.0.0.1:36355
  опрашивается живой узел       127.0.0.1:47039
  cluster-node-timeout          2000 мс

  t=0.00  узел 36355 убит
  t= 0.00  MOVED 12182 127.0.0.1:36355
  t= 3.39  CLUSTERDOWN The cluster is down
  t= 3.49  MOVED 12182 127.0.0.1:39129

  слот перешёл к                127.0.0.1:39129

  вернувшийся узел: его роль    slave
  вернувшийся узел: SET foo     MOVED 12182 127.0.0.1:39129

Три разных ответа, и все три осмысленные: старый адрес слота, честное «слот сейчас не покрыт никем», новый адрес. Клиенту не пришлось гадать ни секунды — узел, до которого он дозвонился, знает состояние всего кластера, потому что узлы непрерывно обмениваются им по шине. И никто не спрашивал внешнюю службу: реплику повысили сами узлы, большинством голосов мастеров.

Под sentinel то же событие выглядит иначе:

9. ОТКАЗ МАСТЕРА ПОД SENTINEL ГЛАЗАМИ КЛИЕНТА
----------------------------------------------------------------------
  мастер по мнению sentinel     127.0.0.1:44393
  down-after-milliseconds       1000 мс

  t=0.00  узел 44393 убит
  t= 0.00  старый адрес: Could not connect to Valkey at 127.0.0.1:44393
  t= 2.30  sentinel называет мастером 127.0.0.1:41979
  новый мастер отвечает на запись OK
  вторая реплика 49651          READONLY You can't write against a read only replica.

Старый адрес не ответил ничего — там никого нет. Ни один узел данных не назвал клиенту нового адреса и не мог: узлы про свою пару не знают, а служба, которая знает, клиенту сама не звонит. Отсюда и правило из спецификации клиента:

Не «желательно», а каждый раз. Почему — в следующем разделе.

Старый мастер вернулся

Это самое опасное место режима Sentinel, и оно не про отказ, а про восстановление. Убитый мастер поднимается обратно — и поднимается мастером: он таким себя помнит, и ничего другого ему пока никто не сказал.

10. СТАРЫЙ МАСТЕР ВЕРНУЛСЯ: САМОЕ ОПАСНОЕ МЕСТО РЕЖИМА SENTINEL
----------------------------------------------------------------------
  мастер сейчас                 127.0.0.1:41979

  t=0.00  узел 44393 поднят обратно
  t= 0.06  роль master, запись -> OK
  t=10.10  роль slave, запись -> READONLY You can't write against a read only replica.

  переведён в реплику через     10.10 с
  сразу после перевода: GET who old
  после синхронизации: GET who  (её нет)

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

В этом опыте в кластере такого окна не возникло, и это проверено тем же прогоном — две последние строки блока 8. Вернувшийся узел узнал из шины, что его слоты уже у другого, ещё до первой команды: роль slave, ответ MOVED на новый адрес.

Слово «в этом опыте» здесь не оговорка вежливости. Проверен был один сценарий — убили и подняли обратно; узел при старте прочитал шину и получил свежую конфигурацию раньше, чем первую команду клиента. Сценарий разделения сети спецификация кластера разбирает отдельно, и там ограниченная потеря записей допускается: клиент с устаревшей картой пишет на бывшего мастера, который ещё не узнал о своей отставке. Мы этого не мерили, и утверждать, что такого окна в кластере не бывает, статья не будет. Измерено другое: в кластере оно закрывается само, а под sentinel — только действиями клиента.

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

Найдено по дороге: готов к работе ≠ готов к отказу

Этот раздел появился из ошибки в замере. Скрипт поднимал кластер, дожидался cluster_state:ok у всех узлов и ронял мастера. Реплика не повышалась — ни через двадцать секунд, ни через минуту, никогда.

Оказалось, что это не поломка замера:

11. СРАЗУ ПОСЛЕ СБОРКИ КЛАСТЕР РАБОТАЕТ, НО ОТКАЗ НЕ ПЕРЕЖИВЁТ
----------------------------------------------------------------------
  cluster-node-timeout              2000 мс
  cluster-replica-validity-factor   10
  repl-ping-replica-period          10

  как расходятся два признака готовности:
    t= 0.01  cluster_state:ok у всех узлов (слоты покрыты, запросы обслуживаются)
    t= 6.08  master_link_status:up у всех реплик (есть кому повышаться)

  окно между ними                   6.07 с

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

  реплика повысилась                НЕТ, за 40 с

  что реплика записала в журнал:
    Currently unable to failover: Disconnected from primary for
     longer than allowed. Please check the
     'cluster-replica-validity-factor' configuration option.

Почему «никогда», а не «пока не истечёт таймаут», видно в исходнике:

if (server.repl_state == REPL_STATE_CONNECTED) {
    data_age = (mstime_t)(server.unixtime - server.primary->last_interaction) * 1000;
} else {
    data_age = (mstime_t)(server.unixtime - server.repl_down_since) * 1000;
}

У реплики, ни разу не подключавшейся к мастеру, repl_down_since равен нулю. Возраст её данных получается отсчитанным от начала эпохи Unix, и никакой допуск такого возраста не покрывает.

Слово «никогда» здесь надо сузить, и сужается оно замером, а не оговоркой. Проверка свежести данных реплики управляется настройкой cluster-replica-validity-factor; в опыте выше у неё значение по умолчанию. Тот же опыт с нулём:

17. ТО ЖЕ ОКНО, НО С ОТКЛЮЧЁННОЙ ПРОВЕРКОЙ СВЕЖЕСТИ
----------------------------------------------------------------------
  cluster-replica-validity-factor         0
  cluster-node-timeout                    2000 мс

  t=0.00  мастер 34455 убит, ждём переключения 40 с
  t= 0.00  состояние кластера ok, роль реплики slave
  t= 3.53  состояние кластера fail, роль реплики slave
  t= 4.15  состояние кластера fail, роль реплики master

  реплика повысилась                      да

Одна строка конфига — и «никогда» превращается в четыре секунды до повышения. Значит, правильная формулировка такая: при значении по умолчанию реплика, не завершившая ни одной синхронизации, не повышается никогда; настройкой это отключается. Совет так делать отсюда не следует: проверка стоит там не зря, и реплика, ни разу не синхронизировавшаяся, повышается ПУСТОЙ — то есть такое переключение лечит доступность ценой данных.

Вывод же не про Valkey, а про эксплуатацию: «кластер поднялся» и «кластер держит отказ» — разные проверки. Первая отвечает, обслуживаются ли запросы; вторая требует смотреть на master_link_status каждой реплики. Автоматика, которая раскатывает кластер и сразу гасит старый, первую пройдёт, а вторую — нет.

Кворум и большинство — разные числа

В настройке sentinel monitor <имя> <адрес> <порт> <кворум> последнее число читают как «сколько sentinel достаточно, чтобы переключить». Это неверно, и документация говорит прямо:

Числа подобраны так, чтобы одно условие выполнялось, а второе нет: пять sentinel, кворум 2, погашены три. Кворум выполнен — и переключения нет:

13. КВОРУМ ОТКРЫВАЕТ ПЕРЕКЛЮЧЕНИЕ, А ВЫПОЛНЯЕТ ЕГО БОЛЬШИНСТВО
----------------------------------------------------------------------
  sentinel в наборе                 5
  кворум в настройке                2
  большинство от пяти               3 (нигде не настраивается)
  мастер                            127.0.0.1:47213

  осталось живых sentinel           2 из 5
  что оставшийся считает мастером   127.0.0.1:47213

  t=0.00  мастер 47213 убит

  за 30 с переключения НЕ произошло 
  кого оставшийся всё ещё зовёт мастером 127.0.0.1:47213

  журнал оставшегося sentinel:
    +sdown master cache 127.0.0.1 47213
    +new-epoch 1
    +vote-for-leader b272810fff90a5f0c6e6fea1106eda051b041c3b 1
    +odown master cache 127.0.0.1 47213 #quorum 2/2
    +new-epoch 2
    +try-failover master cache 127.0.0.1 47213
    +vote-for-leader d7d122dbed4aac4d80d17107ef91b4ae88351035 2

#quorum 2/2 — условие из настройки выполнено, мастер объявлен упавшим. И следом -failover-abort-not-elected: голосов двух из пяти не хватило, чтобы стать ведущим. Стоило поднять одного из погашенных — большинство появилось, и переключение состоялось за две секунды, при том же самом кворуме.

Спрашивать об этом по факту аварии необязательно — есть команда, которая отвечает заранее, и она проверяет оба условия:

18. КАК ПРОВЕРИТЬ КВОРУМ И БОЛЬШИНСТВО ЗАРАНЕЕ, А НЕ ПО ФАКТУ
----------------------------------------------------------------------
  sentinel в наборе / кворум              5 / 2
  живых sentinel                          5
  SENTINEL CKQUORUM cache                 OK 5 usable Sentinels. Quorum and failover authorization can be reached

  живых sentinel                          2
  SENTINEL CKQUORUM cache                 NOQUORUM 2 usable Sentinels. Not enough available Sentinels to reach the majority and authorize a failover

Отказ назван по второму условию прямым текстом: наблюдателей не хватает, чтобы достичь большинства и авторизовать переключение, — при том что кворума из настройки хватает. Это готовый признак для наблюдения: он отвечает на вопрос «переключимся ли мы, если мастер упадёт сейчас», а не «всё ли хорошо прямо сейчас».

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

Чем это отличается от Redis

Вопрос законный: оба механизма Valkey унаследовал от Redis целиком, и до какого-то момента это буквально один и тот же код. Граница названа в самом Valkey, в одном файле с номером версии:

#define VALKEY_VERSION "9.1.2"
 
/* Redis OSS compatibility version, should never
 * exceed 7.2.x. */
#define REDIS_VERSION "7.2.4"

То есть совместимость Valkey объявляет по 7.2.4 — версии, на которой проекты разошлись.

Пользоваться этой строкой как доказательством, однако, нельзя, и это стоит сказать прямо. Она означает ровно одно: до 7.2.4 общее прошлое. Из неё не следует ни что всё до этой точки совпадает сегодня, ни что всё после неё разошлось. Обе стороны с тех пор меняли и то, что было общим. Единственный честный способ сравнивать — брать возможность и смотреть текущую документацию обоих проектов; ниже так и сделано, и результат оказался не тем, к которому подводит рассуждение «появилось в Valkey — значит, в Redis нет».

Первый пример — атомарный перенос слотов, появившийся в Valkey 9.0.

Что здесь важно для читателя: старый способ переноса — тот самый, из-за которого в спецификации живёт перенаправление ASK и предупреждение, что многоключевые операции на время переезда могут отвечать TRYAGAIN. Атомарный перенос эту фазу сокращает.

А вот напрашивающийся вывод «и в Redis такого нет» неверен. В Redis Open Source 8.4 атомарный перенос тоже появился, своей командой:

То есть по состоянию на сегодня возможность есть у обоих, а вот команды и протокол разные: у Valkey это CLUSTER MIGRATESLOTS и внутренняя CLUSTER SYNCSLOTS, у Redis — CLUSTER MIGRATION. Для эксплуатации это разница более практическая, чем «есть или нет»: сценарии переноса и оснастка вокруг них не переносятся между проектами, даже когда возможность называется одинаково.

Всё остальное в этой статье — слоты, MOVED, CROSSSLOT, устройство Sentinel, кворум против большинства — досталось обоим проектам из общего прошлого. На Redis здесь не мерилось ничего, и утверждать «в Redis точно так же» статья не будет: не мерили — не говорим. Ровно это и подвело первую версию раздела.

Что из этого выбирать

Разбор короткий, и он не про производительность.

нужно больше памяти или пропускной способности, чем даёт один узел
    → нативный кластер: это единственный из двух, который шардирует

данные помещаются в один узел, нужна только отказоустойчивость
    → Sentinel остаётся кандидатом

код опирается на многоключевые команды по произвольным ключам
    → Sentinel проще; в кластере придётся сводить ключи в один слот скобками

нужны нумерованные базы
    → Valkey до 9: только Sentinel
    → Valkey 9+: и кластер тоже, через cluster-databases

нужен SWAPDB
    → только Sentinel: в кластере он запрещён и в 9.x

клиент умеет протокол кластера?
    → нет: кластер недоступен без замены клиента или прокси

клиент умеет sentinel?
    → нет: Sentinel недоступен без замены клиента или прокси

Две последние строки стоит прочитать внимательно: ходовое «клиент не умеет sentinel → берите кластер» подводит к мысли, будто кластер прощает клиенту наивность. Не прощает. Обычный клиент, не знающий про кластер, получив MOVED, просто отдаст текст ошибки приложению: карту слотов он не ведёт, повторять по адресу не умеет, ASK и ASKING не знает, TRYAGAIN не обрабатывает. Оба режима требуют своей поддержки в клиенте, и умения эти независимы: библиотека может уметь один, другой, оба или ни одного. Если ни одного — не заработает ни то ни другое, и вопрос переносится с выбора режима на выбор библиотеки или прокси.

Что верно и осталось верным: клиенту кластера достаточно одного живого адреса, чтобы получить карту (блок 3). В проде их всё равно указывают несколько — на случай, если конкретно этот узел недоступен в момент старта.

И ещё одна оговорка про многоключевые команды. Отказ CROSSSLOT — это контракт СЕРВЕРА. Некоторые клиентские библиотеки поверх него делают удобный многоключевой вызов, разбирая его на несколько команд по узлам. Работает это как обёртка, а не как та же команда: атомарности у неё нет, модель отказа другая (часть подзапросов может пройти, часть нет), и задержка складывается из нескольких обращений.

Что должно повториться, а что нет

Числа сняты на Valkey 9.1.2 (собран из исходников — как именно, написано в README каталога bench/valkey-cluster/), на одном хосте, процессы на случайных портах. Скрипты и записи прогонов открываются отсюда: bench/valkey-cluster/.

Секунды не переносятся никуда. Узел считается упавшим через секунду молчания вместо тридцати по умолчанию, cluster-node-timeout — 2000 мс вместо 15 000. Это сделано затем, чтобы набор укладывался в минуты. Десять секунд из блока 10 и 6,07 секунды из блока 11 на ваших настройках будут другими — а вот то, что оба окна существуют, от настроек не зависит.

Дословные ответы сервера переносятся полностью. MOVED, CROSSSLOT, ERR DB index is out of range, READONLY, -failover-abort-not-elected — это поведение, а не измерение, и на той же версии оно будет тем же.

Между версиями — не обязательно. Всё снято на 9.1.2; ни на 8.x, ни на Redis эти прогоны не повторялись. Место, где расхождение заведомо есть, названо выше отдельно.