bench/valkey-cluster/runs/boundaries.txt

Valkey 9.1.2 · один хост, процессы на случайных портах
три утверждения статьи, проверенные на границах

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

  мастер, который упадёт                  127.0.0.1:34455
  его реплика                             127.0.0.1:49949
  master_link_status реплики              down

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

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

  Тот же опыт, что в блоке 12, с единственным отличием в одной строке
  конфига — и другой исход. Значит, «никогда» из блока 12 относится не к
  Valkey вообще, а к значению `cluster-replica-validity-factor` по
  умолчанию: проверку свежести данных реплики можно отключить, и тогда
  она согласится повыситься, не завершив ни одной синхронизации.
  
  Это не совет так делать. Проверка стоит там не зря: реплика, никогда
  не синхронизировавшаяся с мастером, повышается ПУСТОЙ, и переключение
  такого рода лечит доступность ценой данных. Но знать, что поведение
  настраивается, надо — иначе блок 12 читается как неустранимое
  свойство, а он про настройку.

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

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

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

  мастер: ROLE (первое поле)              master
  мастер: CLUSTER INFO                    ERR This instance has cluster support disabled
  мастер: кто мастер по мнению службы     ERR unknown command 'sentinel', with args beginning with: 'get-master-addr-by-name' 'cache'

  Уточнение к формулировке, которая в первой версии статьи была шире
  измеренного. Узел под sentinel знает не «ничего» — он знает свою пару
  репликации: мастер перечисляет подключённые реплики, реплика называет
  адрес мастера и состояние канала. Это настоящая топологическая
  информация, и наблюдению она вполне годится.
  
  Чего он не знает — так это АВТОРИТЕТНОГО ответа на вопрос «кто мастер
  этой службы сейчас». Своё мнение у него есть, и в момент переключения
  оно бывает устаревшим: ровно это и происходит в блоке 10, где
  вернувшийся узел искренне считает мастером себя. Отказ на
  `SENTINEL get-master-addr-by-name` в последней строке — не про
  отсутствие данных, а про то, что эта команда принадлежит другому
  набору и другой службе.