Deep Engineering

ЗАМЕР

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

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

Источники

Скрипт

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()