Redis replication практикум: PSYNC2, diskless, failover и измеримый RPO

Redis традиционно известен как простой и быстрый, но именно в деталях репликации решаются судьбоносные вопросы: сохранность данных (RPO), поведение при обрывах (failover), скорость повторной синхронизации (PSYNC2) и влияние на нагрузку (diskless replication). В этой статье — прикладной взгляд администратора: что включать, как думать о repl-backlog, где пригодится replica-priority, чем помочь Sentinel в выборах лидера и как замерять реальный RPO на вашей инфраструктуре.

Коротко о целях: что хотим от репликации Redis

Нам нужно минимизировать потерю данных при сбоях (RPO), ускорить восстановление кластера (failover) и не утонуть в полных ресинках. Для этого Redis предлагает:

• частичную синхронизацию PSYNC2 с двумя репликационными идентификаторами (replid) и смещениями;
• бездисковую репликацию (diskless), уменьшающую I/O на мастере при полной синхронизации;
• репликационный буфер repl-backlog как основу для PSYNC2;
• настройки, которые ограничивают риск потери данных: min-replicas-to-write, min-replicas-max-lag, а также команды WAIT;
• механику выбора кандидата на промоушен через replica-priority, актуальность offset и логику Sentinel.

PSYNC2: как частичная синхронизация экономит время и снижает риск

Исторически Redis умел только полную синхронизацию: мастеру приходилось делать RDB, реплике — полностью загружать снимок. Механизм PSYNC добавил частичную синхронизацию, а PSYNC2 (актуальная эволюция) сделал её устойчивой к failover: после смены мастера реплики всё ещё способны «достроить» хвост операций, если их смещение есть в repl-backlog и совпали репликационные идентификаторы.

Ключевые сущности PSYNC2:

• Основной репликационный ID (replid) и вторичный ID — позволяют репликам «узнать» новый мастер после failover и выполнить частичную ресинхронизацию;
• Смещение (offset) — число байт, применённых репликой; мастер помнит последний подтверждённый offset для каждой реплики;
• repl-backlog — кольцевой буфер команд на мастере, который хранит историю для частичной синхронизации.

Чем больше repl-backlog, тем выше шанс частичной ресинхронизации без полного RDB после краткого разрыва связи или быстрой смены мастера.

Как выбирать размер repl-backlog

Практический подход: измерьте пиковую запись на мастере в байтах в секунду и помножьте на «худший» сценарий разрыва, который вы готовы покрывать. Добавьте запас 20–50%.

Пример: если пиковая запись — 15 МБ/с, а вы хотите переносить частичной синхронизацией разрывы до 30 секунд, то 15MB/s × 30s = 450MB. Округляя с запасом, ставим repl-backlog-size 512mb. Для бурстов и GC-пауз на виртуалке разумен ещё больший запас.

Не забывайте про repl-backlog-ttl: если все реплики отвалились, через указанный TTL Redis может освободить буфер. В кластерах с частыми перезапусками или rolling-обновлениями поставьте TTL не слишком маленьким, иначе потеряете возможность PSYNC2 и получите лишние полные ресинки.

Diskless replication: когда «стримить по сокету» выгоднее

По умолчанию полный ресинх делается через RDB файл: мастер создаёт снимок на диск, затем отдает его реплике. При высокой нагрузке и медленном хранилище это болезненно. Режим diskless replication позволяет стримить снимок напрямую по сети, без промежуточного файла.

Ключевые параметры мастера:

• repl-diskless-sync yes — включить бездисковую отправку RDB;
• repl-diskless-sync-delay — задержка старта стрима (секунды), чтобы «подождать» остальные реплики и сделать один общий поток;
• repl-disable-tcp-nodelay no — для снижения задержек между мастер-фидом и репликой (оставьте no, если важна минимальная латентность).

На стороне реплик обратите внимание на repl-diskless-load:

• on-empty-db — загружать поток в оперативную память с заменой текущей БД, если она пуста;
• swapdb — подменять базу атомарно без разрывов чтения (полезно для читающих реплик);
• disabled — форсировать загрузку с диска (обычно не нужно, если хватает памяти и сети).

Плюсы diskless: меньше I/O на мастере, один BGSAVE для нескольких реплик, быстрее старт полной синхронизации. Минусы: рост пикового сетевого трафика, повышенные требования к буферам, и более жёсткая нагрузка на CPU во время генерации снапшота.

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

RPO в Redis: чем его ограничить и как реально замерять

RPO (Recovery Point Objective) — сколько данных вы готовы потерять при аварии. В Redis на RPO влияют три фактора:

1. Персистентность на мастере (RDB/AOF и appendfsync).
2. Скорость и гарантия доставки на реплики (сетевой лаг, настройки WAIT, min-replicas-to-write).
3. Актуальность кандидата для промоушена (offset и replica-priority при failover).

Персистентность: RDB и AOF

AOF с appendfsync everysec типично даёт верхнюю границу RPO около одной секунды при краше мастера без успевшего флаша. appendfsync always снижает RPO, но дорого по IOPS. Параллельно это не решает проблему failover: важнее, насколько «свежа» реплика, которая станет мастером.

Доставка на реплики

Два практичных инструмента:

• WAIT — на уровне клиента просим подтверждение от N реплик в течение T миллисекунд. Это даёт полусинхронность для критичных write-путей;
• min-replicas-to-write и min-replicas-max-lag — на уровне сервера запрещают записи, если недостаточно «живых» и не отстающих реплик. Это защита от «одинокого мастера».

Подход к настройке: для систем, где потеря хотя бы десятков миллисекунд данных критична, используйте WAIT в write-операциях; а на конфигурационном уровне выставляйте min-replicas-to-write равным числу локальных реплик (обычно 1 или 2) с лагом 1–3 секунды. Помните, что эти ограничения влияют на доступность записей: при сетевых проблемах мастер начнёт отклонять write-команды.

Кандидат на промоушен

Когда работает Sentinel, он выбирает самую «свежую» реплику по offset, а replica-priority используется как вес. Значение 0 исключает узел из выборов. Так вы можете запретить промоушен удалённых реплик или узлов с HDD.

Sentinel и failover: устойчивые выборы без сюрпризов

Sentinel следит за мастером и репликами, фиксирует недоступность и организует автоматический failover. Для предсказуемых выборов:

• задайте кворум и размер большинства так, чтобы «сплит» сети не дал вам два мастера; как правило, размещайте нечётное число Sentinel в независимых зонах;
• настройте тайминги: down-after-milliseconds не должен быть слишком малым (ложные срабатывания на пиках CPU), и failover-timeout — разумным для вашей сети;
• отдайте предпочтение репликам в том же DC, где был мастер: replica-priority локальным меньше (лучше), удалённым — больше или 0;
• ограничьте параллелизм подтягивания реплик к новому мастеру через parallel-syncs, чтобы не обрушить I/O.

Важно помнить, что при промоушене Sentinel перефокусирует остальные реплики на нового мастера и, благодаря PSYNC2 с двойными replid, у вас часто получится частичная, а не полная ресинка. Это экономит время и снижает риск избыточной нагрузки.

Практическая конфигурация: опорные значения

Мастер (основные параметры)

repl-diskless-sync yes
repl-diskless-sync-delay 5
repl-backlog-size 512mb
repl-backlog-ttl 60
min-replicas-to-write 1
min-replicas-max-lag 3
repl-timeout 60
repl-disable-tcp-nodelay no
client-output-buffer-limit replica 512mb 128mb 120

Комментарий:

• repl-backlog-size рассчитывайте по вашему пиковому write-трафику;
• client-output-buffer-limit replica увеличьте, если бывают длинные RTT или bursts pub/sub;
• min-replicas-to-write подбирайте по количеству локальных реплик.

Реплика

replicaof 10.0.0.1 6379
masteruser repl
masterauth S3cr3t
replica-read-only yes
replica-priority 100
repl-diskless-load swapdb

Комментарий:

• replica-priority 0 — запрет на промоушен (например, для дальнего DC);
• swapdb снижает заметность переключений для читающих реплик;
• используйте выделенного пользователя ACL для репликации (masteruser/masterauth).

Sentinel

sentinel monitor cacheA 10.0.0.1 6379 2
sentinel down-after-milliseconds cacheA 5000
sentinel failover-timeout cacheA 180000
sentinel parallel-syncs cacheA 1
sentinel auth-user cacheA repl
sentinel auth-pass cacheA S3cr3t

Расставьте Sentinel по разным узлам, избегайте совместного размещения всех экземпляров в одной зоне отказа. Кворум подбирайте так, чтобы ни одна часть сети при разделении не могла в одиночку «избрать» нового мастера без большинства.

Построение топологий: от простого к надёжному

Минимум: мастер + 1 реплика в том же DC + 1 Sentinel-кворум из трёх в разных зонах. Для междата-центровых схем используйте «цепочку»: реплика в удалённом DC может подписываться на локальную реплику, а не на мастер. Такой hop снижает междата-центровый RTT на мастере. Эту промежуточную реплику явно исключите из промоушена (replica-priority 0), чтобы при локальном failover не возникла «переездка» мастера в другой регион.

Если у вас несколько приложений с разной чувствительностью к RPO, задумайтесь о смешанном подходе: базовые write-пути с WAIT и строгими min-replicas-to-write, а фоновые операции — без WAIT, чтобы не задерживать поток при временных проблемах сети. Для внешнего трафика и региональной устойчивости посмотрите материал про взвешенный GeoDNS и failover.

Если вы строите кэш-слой и сессии, пригодится обзор по использованию Redis для сессий и object cache в PHP.

Мониторинг и измерение RPO/лага

RPO в Redis можно оценивать в байтах и секундах. На мастере есть master_repl_offset, на каждой реплике — её текущий offset. Разница в offset — это невоспроизведённый хвост. В секундах лаг полезно смотреть как средний RTT доставки команд плюс время на запись репликой.

Практические метрики и проверки:

• разница offset мастер vs реплика;
• число частичных vs полных ресинхронизаций за сутки;
• время полной ресинки (diskless vs обычная);
• времена failover от «потери мастера» до «новый мастер принимает запись»;
• процент write-операций, использующих WAIT, и процент таймаутов;
• заполняемость repl-backlog относительно его размера.

Чек-лист снижения RPO

• Подберите repl-backlog-size под ваш write-объём и худший разрыв соединения.
• Включите repl-diskless-sync и выставьте repl-diskless-sync-delay ≥ 3–5 секунд, чтобы агрегировать одновременные полные ресинки.
• На критичных путях используйте WAIT с разумным таймаутом.
• Задайте min-replicas-to-write и min-replicas-max-lag, чтобы блокировать запись на «одинокий» мастер.
• Отдайте приоритет локальным репликам через replica-priority, удалённые сделайте непригодными (0), чтобы не получить межрегиональный failover.
• Проверьте client-output-buffer-limit replica, чтобы реплики с высоким RTT не отваливались по переполнению буфера.
• Заложите алерты на превышение лага и на долю полных ресинков.

Тест-план: воспроизводим ваш failover с метриками

1. Нагрузите кластер синтетическими записями с контролируемым RPS и размером payload. Зафиксируйте пиковый байтовый поток.
2. Проверьте, что repl-backlog покрывает хотя бы 30–60 секунд такого потока.
3. Имитируйте обрыв соединения реплики на 10–20 секунд. Убедитесь, что после возврата была частичная ресинка (PSYNC2), а не полная.
4. Искусственно «роняйте» мастер (остановка процесса или изоляция сети) и фиксируйте: время до объявления недоступности Sentinel, время до промоушена, объём потерянных данных (по offset и по приложению).
5. Повторите с удалённой репликой и убедитесь, что она не становится мастером, если у неё replica-priority 0.
6. Замерьте эффект WAIT: долю запросов, получивших подтверждение N реплик в заданный таймаут.

Для быстрого стенда под испытания удобно поднять узлы на облачном VDS: так проще варьировать CPU, RAM и диски под пиковый write-трафик и тесты diskless ресинков.

Тонкости и частые проблемы

• Подрезанный backlog: слишком маленький repl-backlog-size приводит к полным ресинкам даже при кратких разрывах. Симптом — частые FULLRESYNC.
• Переполнение буфера реплики: если RTT и throughput высокие, увеличьте client-output-buffer-limit replica, иначе мастер будет разрывать соединение.
• Ложные failover: слишком маленький down-after-milliseconds в Sentinel при пиках CPU и GC приводит к «миганию» мастера. Увеличьте порог и следите за системными метриками.
• Слабый диск мастера: без diskless при одновременной полной ресинке нескольких реплик мастер упрётся в I/O. Включите repl-diskless-sync и соберите реплики одной сессией через задержку.
• Несинхронный промоушен дальнего DC: задайте replica-priority 0 удалённым узлам, чтобы не получить «мастер далеко» и высокий RPO из-за сетевой задержки.

Итоги

PSYNC2 и корректно подобранный repl-backlog — фундамент быстрого восстановления и экономии на полных ресинках. Diskless replication снимает лишний I/O при полной синхронизации. Настройки WAIT, min-replicas-to-write и replica-priority — ваши рычаги для снижения RPO и предсказуемого failover. Возьмите за правило: измеряйте write-трафик, моделируйте аварии, фиксируйте RPO в байтах и секундах, корректируйте конфигурацию — и у вас будет надёжный Redis, который ведёт себя как ожидается.