ЗАМЕР

bench/valkey-cluster/runs/notready.txt

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

Цитируется в статье: /ru/system-design/caching/valkey-clustering

Запись прогона

У этого замера записи прогона нет — только скрипт.

Скрипт

53 строк

Valkey 9.1.2 · один хост, процессы на случайных портах
окно между «кластер собран» и «кластер переживёт отказ»

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 с

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

12. ЧТО БУДЕТ, ЕСЛИ МАСТЕР УПАДЁТ ВНУТРИ ЭТОГО ОКНА
----------------------------------------------------------------------
  мастер, который упадёт            127.0.0.1:39151
  его реплика                       127.0.0.1:48151
  master_link_status реплики        down
  master_link_down_since_seconds    -1

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

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

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

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