ЗАМЕР
bench/valkey-cluster/quorum.py
Скрипт, которым получены числа в статье, и запись прогона. Файл читается на сборке из репозитория — это тот самый код, который запускали, а не его копия.
- Цитируется в статье
- /ru/system-design/caching/valkey-clustering
- Как запустить
python3 bench/valkey-cluster/discovery.py # блоки 1-4 python3 bench/valkey-cluster/apidiff.py # блоки 5-7 python3 bench/valkey-cluster/failover.py # блоки 8-10 python3 bench/valkey-cluster/notready.py # блоки 11-12 python3 bench/valkey-cluster/quorum.py # блок 13 python3 bench/valkey-cluster/databases.py # блоки 14-16 python3 bench/valkey-cluster/boundaries.py # блоки 17-19
Запись прогона
Замеры для статьи «Два способа собрать Valkey из нескольких узлов»
| Файл | Что делает |
|---|---|
common.py |
подъём узлов в обоих режимах, разговор с ними, печать блоков. Общий модуль, сам ничего не печатает |
discovery.py |
как клиент находит узел: MOVED против SENTINEL get-master-addr-by-name, и что клиент делает на самом деле — блоки 1–4 |
apidiff.py |
какие команды в кластере перестают работать и почему — блоки 5–7 |
failover.py |
отказ мастера в обоих режимах глазами клиента, и что бывает, когда старый мастер возвращается — блоки 8–10 |
notready.py |
окно между «кластер собран» и «кластер переживёт отказ» — блоки 11–12 |
quorum.py |
кворум против большинства: почему одно число не заменяет другое — блок 13 |
databases.py |
нумерованные базы в кластере: два кластера с разным cluster-databases — блоки 14–16 |
boundaries.py |
три утверждения статьи, проверенные на границах — блоки 17–19 |
python3 bench/valkey-cluster/discovery.py # блоки 1-4
python3 bench/valkey-cluster/apidiff.py # блоки 5-7
python3 bench/valkey-cluster/failover.py # блоки 8-10
python3 bench/valkey-cluster/notready.py # блоки 11-12
python3 bench/valkey-cluster/quorum.py # блок 13
python3 bench/valkey-cluster/databases.py # блоки 14-16
python3 bench/valkey-cluster/boundaries.py # блоки 17-19
Нужен собранный Valkey — путь к нему берётся из VALKEY_BIN (по умолчанию
/usr/local/valkey912/bin). Узлы поднимаются во временных каталогах на
случайных портах и убиваются в finally; после себя скрипты не оставляют ни
процессов, ни файлов. Весь набор идёт около шести минут: переключений надо
дождаться несколько раз, и торопить их нечем.
Откуда здесь Valkey 9.1.2
В системных пакетах лежит 7.2.13 — ветка, к которой половина того, что стоит
писать про кластер, уже не относится. Обычный путь за свежей версией закрыт:
dl.google.com и сайт проекта недоступны из этой среды. Зато доступен GitHub, а
Valkey собирается из исходников одной командой:
git clone --depth 1 --branch 9.1.2 https://github.com/valkey-io/valkey.git /tmp/valkey912
cd /tmp/valkey912 && make -j2 BUILD_TLS=no
install -D /tmp/valkey912/src/valkey-{server,cli,benchmark} -t /usr/local/valkey912/bin
Отдельного двоичного файла для sentinel нет и не нужно: это тот же
valkey-server, запущенный с конфигом и флагом --sentinel. Свойство, а не
деталь сборки, — и в блоке 7 видно, чем режимы при этом отличаются.
Что здесь важно прочитать правильно
Абсолютные секунды не переносятся никуда. Узел считается упавшим через
секунду молчания (down-after-milliseconds 1000) вместо тридцати по умолчанию,
а cluster-node-timeout стоит 2000 мс вместо 15 000. Это сделано ровно затем,
чтобы набор укладывался в минуты. Содержательны порядок событий, текст ответов
сервера и знак разницы — но не число секунд.
Порты выбираются ниже 55535, и это не придирка. Узел кластера слушает два порта: обычный и шинный, ровно на десять тысяч больше. Порт из эфемерного диапазона даёт шинный порт больше 65535, и узел не поднимается вовсе.
Опрос идёт «глупым» клиентом. Везде, где печатается ответ сервера, он снят
через valkey-cli без флага -c. Библиотека-клиент прячет ровно то, что здесь
интересно: сама ходит за картой слотов, сама повторяет запрос, сама спрашивает
sentinel. Настоящие клиентские библиотеки используются только в блоках 3 и 4 —
там вопрос как раз в том, что делает клиент, и считают это сами узлы.
Что получилось
Как клиент находит узел
| нативный кластер | Sentinel | |
|---|---|---|
| кто знает топологию | каждый узел данных | отдельная служба |
| что клиент спрашивает | любой узел, обычной командой | SENTINEL get-master-addr-by-name |
| как узнаёт про чужой ключ | MOVED 12182 127.0.0.1:43425 |
никак: вопрос не к узлу |
| что нужно в конфиге клиента | один живой адрес узла | адреса sentinel и имя набора |
В блоке 3 видно, что клиент кластера, получив ОДИН адрес из шести, сходил за
CLUSTER SLOTS и дальше писал напрямую нужному узлу. В блоке 4 порядок
обратный: сначала вопрос службе, потом команда данным.
Что ломается в кластере из привычного
| команда | в кластере | под sentinel |
|---|---|---|
MSET foo 1 bar 2 |
CROSSSLOT Keys in request don't hash to the same slot |
OK |
MSET {u}:a 1 {u}:b 2 |
работает: общая скобка кладёт ключи в один слот | OK |
SELECT 1 |
ERR DB index is out of range — но см. ниже |
OK |
SWAPDB 0 1 |
ERR SWAPDB is not allowed in cluster mode |
OK |
Две формы отказа различаются не случайно: SWAPDB запрещён как таковой, а
SELECT 1 — выход за границу. За какую именно границу, блок 6 сам по себе не
говорит, и на этом первая версия статьи ошиблась.
Нумерованные базы: настройка, а не режим
Из SELECT 1 → ERR DB index is out of range в первой версии был сделан вывод
«в кластере база ровно одна». Это правило Redis и Valkey до 9.0; в Valkey 9.0
нумерованные базы в кластере появились, а их число задаёт неизменяемая
настройка cluster-databases со значением по умолчанию 1. Блоки 14–16
поднимают два кластера, отличающихся ровно этой строкой:
| кластер А | кластер Б | |
|---|---|---|
cluster-databases |
1 | 16 |
SELECT 1 |
ERR DB index is out of range |
OK |
SELECT 15 |
ERR DB index is out of range |
OK |
SELECT 16 |
ERR DB index is out of range |
ERR DB index is out of range |
Номер базы в адресацию не входит: один ключ в базах 0 и 1 держит разные
значения при одном слоте 12182. А вот чего базы не дают — общего на кластер
представления о себе: DBSIZE и SCAN считают только ту часть базы, что лежит
на узле, куда пришла команда, SWAPDB остаётся запрещён.
Границы трёх утверждений
Блоки 17–19 перемеряют места, где статья сказала шире измеренного:
«никогда» из блока 12 снимается настройкой cluster-replica-validity-factor 0
(реплика повышается за четыре секунды, но пустой); границу кворума и
большинства заранее показывает SENTINEL CKQUORUM; узел под sentinel знает не
«ничего», а свою пару репликации — не знает он только авторитетного ответа
службы.
Отказ мастера
| нативный кластер | Sentinel | |
|---|---|---|
| кто замечает | сами узлы, по шине | отдельные наблюдатели |
| кто решает | большинство мастеров | большинство sentinel |
| что получает клиент в этот момент | CLUSTERDOWN, потом MOVED на новый адрес |
молчание старого адреса |
| как клиент узнаёт новый адрес | из ответа любого живого узла | только спросив sentinel |
| вернувшийся старый мастер | сразу реплика, отдаёт MOVED |
мастер на 10 с, принимает записи |
Последняя строка — самое опасное место режима Sentinel и содержание блока 10.
Вернувшийся узел поднимается мастером, отвечает OK на записи, а после
перевода в реплику полная синхронизация их стирает. Клиент при этом не видит ни
одной ошибки.
Два состояния готовности
Блоки 11 и 12 — про находку, ради которой стоило ронять узлы вручную. Между
«слоты розданы» (cluster_state:ok) и «есть кому повышаться»
(master_link_status:up у реплик) прошло 6,07 секунды. Мастер, упавший
внутри этого окна, не заменяется НИКОГДА: у реплики, ни разу не подключавшейся,
отметка «когда упал канал» осталась нулевой, возраст её данных считается от
начала эпохи Unix, и она отказывается повышаться:
Currently unable to failover: Disconnected from primary for longer than
allowed. Please check the 'cluster-replica-validity-factor' configuration
option.
Условие видно в исходнике (src/cluster_legacy.c):
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;
}
Практический вывод про эксплуатацию: «кластер поднялся» и «кластер держит
отказ» — разные проверки, и вторая смотрит на master_link_status каждой
реплики.
Кворум и большинство
Пять sentinel, кворум 2, погашены три. Кворум выполнен — и переключения всё равно нет:
+odown master cache 127.0.0.1 48147 #quorum 2/2
+try-failover master cache 127.0.0.1 48147
+vote-for-leader c92cd70b21a9dd26ec40e67185371e78ee502f9a 1
-failover-abort-not-elected master cache 127.0.0.1 48147
Стоило поднять одного из погашенных — большинство появилось, и переключение состоялось за две секунды. Кворум при этом не менялся вовсе.
Источники
- Valkey. Cluster specification — https://valkey.io/topics/cluster-spec/
- Valkey. High availability with Valkey Sentinel — https://valkey.io/topics/sentinel/
- Valkey. Sentinel client spec — https://valkey.io/topics/sentinel-clients/
- Valkey. Atomic slot migration — https://valkey.io/topics/atomic-slot-migration/
- Valkey. Numbered Databases in Valkey 9.0 — https://valkey.io/blog/numbered-databases/
- Redis. CLUSTER MIGRATION — https://redis.io/docs/latest/commands/cluster-migration/
- Исходники Valkey 9.1.2 — https://github.com/valkey-io/valkey/tree/9.1.2
Скрипт
176 строк"""Кворум и большинство — два разных числа, и путают их постоянно. Блок 13.
ЧТО ЗДЕСЬ ПРОВЕРЯЕТСЯ. В настройке `sentinel monitor <имя> <адрес> <порт>
<кворум>` последнее число задаёт, сколько наблюдателей должны согласиться, что
мастер упал. Его читают как «сколько sentinel достаточно, чтобы переключить», и
это неверно: согласие открывает процедуру, а выполнить её может только тот, кого
выбрало БОЛЬШИНСТВО ВСЕХ известных sentinel. Числа разные, и второе настройкой
не задаётся вовсе.
КАК ЭТО ПОКАЗАНО. Пять sentinel, кворум 2 — и гасятся ТРИ. Остаются двое: их
ровно столько, сколько требует кворум, и меньше, чем большинство от пяти.
Дальше роняется мастер, и печатается, что выжившие записали у себя в журнале.
Числа подобраны именно так, чтобы одно условие выполнялось, а второе нет: на
трёх sentinel с кворумом 2 оба ломаются одновременно, и разницу не увидеть.
ЗАПУСК: python3 bench/valkey-cluster/quorum.py
"""
from __future__ import annotations
import time
from common import (
Cluster,
cli,
free_port,
head,
master_addr,
note,
preamble,
row,
)
SENTINEL_NAME = "cache"
PAD = 34
INTERESTING = (
"+sdown master", "+odown master", "+new-epoch", "+try-failover",
"+vote-for-leader", "+elected-leader", "+switch-master",
"-failover-abort-not-elected", "-odown master",
)
def journal(cluster: Cluster, port: int, since: int) -> int:
"""Напечатать журнал до КОНЦА ПЕРВОГО круга попытки переключения.
Круг повторяется с новой эпохой снова и снова, пока мастер молчит, и
печатать их все — значит утопить содержательное в повторе. Печатается один
круг целиком и отдельной строкой то, сколько их было всего.
"""
lines = cluster.sentinel_log(port)
shown, rounds = 0, 0
for line in lines[since:]:
for mark in INTERESTING:
if mark in line:
text = line.split(" # ")[-1].split(" * ")[-1]
if rounds == 0:
print(" " + text[:66])
shown += 1
if "-failover-abort-not-elected" in text:
rounds += 1
elif rounds > 0 and "+try-failover" in text:
rounds += 1
break
if rounds:
print(" ... и так по кругу, с новой эпохой каждый раз, пока мастер молчит")
return len(lines)
def main() -> None:
preamble("пять sentinel, кворум 2: что открывает кворум и что решает большинство")
cluster = Cluster()
try:
master = free_port()
replicas = [free_port(), free_port()]
sentinels = [free_port() for _ in range(5)]
cluster.start_data(master)
for r in replicas:
cluster.start_data(r, replicaof=master)
for s in sentinels:
cluster.start_sentinel(s, master, quorum=2, name=SENTINEL_NAME)
time.sleep(4)
head(13, "КВОРУМ ОТКРЫВАЕТ ПЕРЕКЛЮЧЕНИЕ, А ВЫПОЛНЯЕТ ЕГО БОЛЬШИНСТВО")
row("sentinel в наборе", str(len(sentinels)), pad=PAD)
row("кворум в настройке", "2", pad=PAD)
row("большинство от пяти", "3 (нигде не настраивается)", pad=PAD)
row("мастер", f"127.0.0.1:{master}", pad=PAD)
print()
watcher = sentinels[0]
mark = len(cluster.sentinel_log(watcher))
# Гасятся ТРИ sentinel из пяти. Набор при этом не меняется: выжившие
# по-прежнему считают, что их пятеро, — они просто перестанут получать
# от погашенных голоса.
for s in sentinels[2:]:
cluster.kill(s)
time.sleep(2)
row("осталось живых sentinel", "2 из 5", pad=PAD)
row("что оставшийся считает мастером",
":".join(map(str, master_addr(watcher, SENTINEL_NAME) or ("?", "?"))), pad=PAD)
print()
cluster.kill(master)
print(f" t=0.00 мастер {master} убит")
t0 = time.time()
switched = None
while time.time() - t0 < 30:
addr = master_addr(watcher, SENTINEL_NAME)
if addr and addr[1] != master:
switched = addr
break
time.sleep(0.2)
print()
if switched:
row("переключение произошло", f"{switched[0]}:{switched[1]}", pad=PAD)
else:
row("за 30 с переключения НЕ произошло", "", pad=PAD)
row("кого оставшийся всё ещё зовёт мастером",
":".join(map(str, master_addr(watcher, SENTINEL_NAME) or ("?", "?"))), pad=PAD)
print()
print(" журнал оставшегося sentinel:")
journal(cluster, watcher, mark)
# Проверка обратного: вернуть ОДИН погашенный — и большинство (3 из 5)
# снова есть, при том же самом кворуме.
print()
cluster.start_sentinel(sentinels[2], master, quorum=2, name=SENTINEL_NAME)
print(" поднят ещё один sentinel: живых стало 3 из 5, кворум тот же")
t0 = time.time()
after = None
while time.time() - t0 < 40:
addr = master_addr(watcher, SENTINEL_NAME)
if addr and addr[1] != master:
after = addr
break
time.sleep(0.2)
print()
if after:
row("переключение произошло через", f"{time.time() - t0:.2f} с после этого", pad=PAD)
row("новый мастер", f"{after[0]}:{after[1]}", pad=PAD)
row("он принимает запись", cli(after[1], "set", "k", "v"), pad=PAD)
else:
row("за 40 с переключения так и НЕ произошло", "", pad=PAD)
note(
"""
Журнал читается подряд, и в нём видны обе стадии. Сначала
+odown: кворум собран, мастер объявлен упавшим — это ровно то
число, что стоит в настройке, и оно выполнилось. Потом
+try-failover и +vote-for-leader: выживший sentinel пытается
стать ведущим. И следом -failover-abort-not-elected: голосов двух
из пяти не хватило, чтобы им стать, и переключение отменено.
То есть кворум отвечает на вопрос «сломалось ли», а большинство —
на вопрос «кому чинить». Второе число нигде не настраивается: это
всегда большинство ОТ ЧИСЛА ИЗВЕСТНЫХ sentinel, и уменьшить его,
понизив кворум, нельзя.
Отсюда практическое правило, которое из одной настройки не
выводится: потерю большинства sentinel система не переживёт, каким
бы низким ни был кворум, — а значит, ставить их надо нечётным
числом и в разные места отказа. Вторая половина блока это и
показывает: кворум не менялся вовсе, вернулся ровно один
наблюдатель, и переключение, стоявшее насмерть, состоялось.
"""
)
finally:
cluster.stop_all()
if __name__ == "__main__":
main()