Понимание отставания репликации Redis: PSYNC, размер и ограничения высокой доступности

Der Задержка репликации Redis определяет, будет ли реплика после обрыва соединения загружать только пропущенные изменения или ей потребуется повторная передача всего набора данных. Если размер буфера рассчитывать исходя из фактического объема репликации, можно избежать ненужных полных синхронизаций. Однако для этого должны согласовываться история репликации, бюджет хранения и рабочие процессы: большой накопившийся объем данных не заменяет ни персистентности, ни надёжной концепции переключения на резервный сервер.

Что на самом деле хранится в списке незавершенных задач

На сайте Репликация Redis Первичный сервер обрабатывает изменения в наборе данных и передает непрерывный поток команд своим репликам. Сюда входят не только значения, непосредственно записанные клиентами. Истекшие или вытесненные ключи также могут вызывать изменения, которые необходимо передать. Backlog хранит в оперативной памяти ограниченный фрагмент этого потока репликации, относящийся к последнему периоду времени. Поэтому он не содержит дополнительной полной копии базы данных и не является архивом записей произвольной давности.

При бесперебойной работе реплики синхронизируются с текущим состоянием. Если соединение прерывается, история на первичном сервере продолжает пополняться. После восстановления соединения реплика пытается продолжить работу с того места, на котором остановилась. В этом случае решающим фактором является наличие необходимых байтов в памяти. Если это так и история репликации совпадает, Redis может восполнить пробел. Для этого нет необходимости полностью заменять уже имеющиеся данные на реплике.

Преимущества особенно заметны при кратковременных сбоях в работе сети, смене соединения и плановых работах по техническому обслуживанию. Полная синхронизация большого массива данных требует пропускной способности канала и вычислительной мощности; в зависимости от конфигурации к этому добавляется дополнительная нагрузка на систему хранения и носители данных. Функция «Backlog» может снизить эти затраты, но не способна компенсировать все виды сбоев. Перезапуск процесса или изменение истории требуют иного подхода, чем кратковременное обрывание TCP-соединения.

Когда достаточно PSYNC, а когда требуется полная пересинхронизация

A частичная ресинхронизация с помощью PSYNC требует двух взаимосвязанных параметров: идентификатора репликации и смещения. Идентификатор обозначает конкретную историю данных. Смещение описывает позицию в байтах внутри потока репликации. Поэтому два смещения одинакового размера из разных историй не всегда можно сравнивать напрямую. И наоборот, небольшое отставание в одной и той же истории может уже выходить за пределы доступного бэклога, если его емкость ограничена.

Проще говоря, при повторном подключении реплика сообщает, до какого момента она дошла. Первичный сервер проверяет, может ли он предоставить необходимые данные для дальнейшей работы. Если история неизвестна или отсутствует необходимый фрагмент, то Полная пересинхронизация необходимо. При этом реплика получает полный набор данных, а затем — изменения, возникшие в ходе синхронизации. В зависимости от конфигурации передача данных на носитель может осуществляться с промежуточным этапом RDB или без него.

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

Измерять скорость репликации вместо того, чтобы оценивать размер базы данных

Одного лишь объема массива данных достаточно для Расчет объема невыполненных заказов не всегда так. Большая база данных, в которой преобладают операции чтения, может генерировать небольшой объем трафика репликации. Напротив, небольшой кэш с часто меняющимися значениями и большим количеством событий истечения срока действия может постоянно передавать значительные объёмы данных. Даже фиксированное количество операций в секунду недостаточно точно описывает необходимый объём памяти: небольшие изменения ключей и перезапись больших значений занимают разный объём в байтах.

Практически применимое приближение получается из временного прироста master_repl_offset. Зафиксируйте значение дважды на одном и том же первичном сервере и разделите разницу на количество прошедших секунд. При этом также проверьте идентификатор репликации. После смены роли или перезапуска нельзя просто вычитать друг из друга два несвязанных между собой измерения. Кроме того, отдельный интервал измерения даёт лишь среднюю частоту в пределах этого интервала, а не гарантированный в долгосрочной перспективе верхний предел.

Следующий запрос считывает диагностическую информацию. Он не изменяет настройки Redis. Выполните его с использованием параметров подключения и аутентификации, необходимых для вашей среды. Приведенный ниже вызов использует стандартное подключение из redis-cli; необходимо явно указать другой хост, порт или доступ по протоколу TLS.

redis-cli INFO replication

Проведите измерения в различных фазах нагрузки, например, в ходе обычной повседневной работы, при импорте данных и во время масштабных обновлений кэша. Зафиксируйте как типичные показатели, так и кратковременные пики. Если возникает много изменений из-за истечения срока действия ключей, для более глубокого изучения темы полезно ознакомиться с внутренней статьей Анализ срока действия ключей Redis. Эта взаимосвязь важна для планирования, поскольку не каждый значимый импульс для написания текста возникает непосредственно в результате нового запроса пользователя.

Прозрачный расчет объема заказов в портфеле

Как Приблизительный план ты можешь умножить соответствующую скорость репликации на продолжительность перерыва, который необходимо преодолеть, а затем добавить обоснованный запас времени. При расчёте продолжительности следует учитывать не только само прерывание связи. Время может потребоваться также на обнаружение сбоя, попытки повторного подключения и восстановление канала связи. Какой запас времени будет адекватным, зависит от наблюдаемых колебаний и желаемого уровня работоспособности, а не от какого-то универсального процентного значения.

Намеренно упрощенный расчетный пример: для рассматриваемой фазы нагрузки ты берешь 12 MiB в секунду. Соединение может отсутствовать в течение 90 секунд; ещё 30 секунд заложено в качестве временного запаса. Отсюда следует, что 12 MiB/s × 120 s = 1.440 MiB, то есть примерно 1,41 GiB. Эти цифры приведены в качестве примера для пояснения и не являются результатами тестирования Redis. Перед внедрением в производственную среду их необходимо заменить на данные, полученные в ходе тестирования вашего приложения.

Обратный расчет помогает определить объем имеющегося буфера. Полностью заполненный бэклог объемом 256 MiB при постоянной скорости 12 MiB в секунду теоретически соответствует примерно 21 секунде истории. При скорости 2 MiB в секунду это составило бы примерно 128 секунд. Однако в реальных условиях скорости передачи данных меняются. Поэтому такой диапазон является лишь моментальным снимком и не гарантирует, что каждое нарушение этой продолжительности может быть частично синхронизировано.

Кроме того, проверьте, сможет ли реплика после восстановления соединения наверстывать отставание быстрее, чем появляются новые изменения. Увеличение объема истории не устраняет ни постоянно медленную сеть, ни постоянно перегруженный получатель. Если отставание сохраняется или продолжает расти, необходимо выяснить его причину. В противном случае увеличение объема памяти лишь отложит проблему и может создать нагрузку на память всей системы.

Как легко и контролируемо изменять настройки Redis

Параметры repl-backlog-size и repl-backlog-ttl управляют разными параметрами. Первый описывает запланированный размер накопившегося объема задач. Второй определяет на первичном сервере, через какое время после отсутствия подключенных реплик накопившийся объем задач может быть освобожден. Он отсутствие максимальной продолжительности перерыва для PSYNC. Пока буфер перезаписывается или отсутствует какое-либо другое необходимое условие, один лишь большой TTL не поможет.

Приведенные ниже строки взяты из шаблона конфигурации Redis 7.2.0 в виде закомментированных настроек. Знаки комментариев сохранены намеренно. Простое копирование этих строк не приводит к активации настроек; кроме того, указанные значения не являются общими рекомендациями по масштабируемости для производственных систем.

# Redis 7.2.0: auskommentierte Vorgaben aus redis.conf
# repl-backlog-size 1mb
# repl-backlog-ttl 3600

С repl-backlog-ttl 0 После отключения всех реплик отключается и временная блокировка. При этом не сохраняется неограниченная история: имеющийся буфер по-прежнему может быть перезаписан новыми данными репликации. Кроме того, это не обеспечивает сохранность данных при любых перезапусках процесса. Поэтому тщательно оцените, соответствует ли дополнительное потребление памяти ожидаемому поведению при повторном подключении.

Перед внесением изменений следует запросить фактические действующие значения и уточнить процедуру развертывания. Переменная среды контейнера, управляемый файл конфигурации и настройка, измененная во время выполнения, — это не одно и то же. Если позже будет создана новая инстанция, могут быть утеряны только те настройки, которые были внесены во время выполнения. Следующие запросы являются запросами для чтения; тем не менее, для их выполнения требуются соответствующие права доступа.

redis-cli CONFIG GET repl-backlog-size
redis-cli CONFIG GET repl-backlog-ttl

В случае Managed Redis поставщик может ограничить доступ к CONFIG ограничивать или управлять настройками через собственный интерфейс. Это не повод для обхода механизмов защиты. В таком случае используйте разрешенные способы администрирования и задокументируйте выбранный размер вместе с базовым объемом репликации. Кроме того, в плане изменений следует зафиксировать предыдущие значения и реалистичный план возврата к исходному состоянию.

Мониторинг: какие показатели взаимосвязаны

Для Мониторинг репликации Redis Одного зеленого индикатора состояния соединения недостаточно. Соединение может быть восстановлено, в то время как реплика ещё наверстывает отставание или как раз загружает полный набор данных. И наоборот, кратковременный обрыв соединения не обязательно является критическим, если история данных и резервные возможности для наверстывания отставания достаточны. Поэтому оценивайте соединение, состояние синхронизации, динамику смещения и доступную историю в совокупности.

Поля в INFO-Ответы могут различаться в зависимости от версии Redis, а также между первичным сервером и репликой. Поэтому при анализе данных следует явно учитывать отсутствующие поля, а не молчаливо интерпретировать их как нулевые значения или как отсутствие ошибок. Также обозначения master и slave по-прежнему встречаются в именах полей из соображений совместимости; их нельзя произвольно переводить в исполняемом коде.

Для интерпретации отставания следует руководствоваться внутренним руководством Анализ смещения репликации Redis подходящее дополнение. При текущем мониторинге тебе следует учитывать исторические тенденции, а не только два числа, снятые вручную. Растущий разрыв требует иной реакции, чем разрыв, который после кратковременного отставания неуклонно сокращается.

Эффективные оповещения должны ориентироваться на ваши операционные цели: как долго реплика может оставаться недоступной? Как быстро она должна восстановить работу? Какая частота полных синхронизаций считается необычной? Жесткие пороговые значения, не учитывающие профиль нагрузки и объём данных, часто приводят к появлению ненужных уведомлений или позволяют упустить из виду реальные ухудшения. Помимо показателей репликации, следите также за загрузкой ОЗУ, загрузкой сети и признаками перезапуска процессов.

Правильная оценка бюджета хранения и медленных реплик

Портфель заказов — это лишь часть всего Требования к памяти Redis. К этому следует добавить набор данных, административные структуры, буфер клиента и, в зависимости от рабочего состояния, дополнительную память во время операций сохранения или синхронизации. Поэтому не следует планировать использование всего доступного объёма оперативной памяти для пользовательских данных плюс точно рассчитанного объёма невыполненных задач. Необходимый резерв должен определяться исходя из конкретной среды и пиковых нагрузок, возникающих в ней.

Начиная с Redis 7.0, буфер реплик и очередь репликации используют общий объем памяти. Поэтому в документации INFO, в частности, отмечается, что mem_clients_slaves может равняться нулю, если буферы реплик не превышают загрузку бэклога. Из этого не следует, что репликация не занимает памяти. Рассмотрите предусмотренные для этого значения, такие как mem_replication_backlog и mem_total_replication_buffers учитывайте контекст и не суммируйте перекрывающиеся величины бездумно.

Частая ошибка при диагностике заключается в том, что каждую прерванную синхронизацию пытаются объяснить значительным отставанием в обработке данных. Медленная работа реплик, ограниченная пропускная способность сети или превышение предельных значений выходного буфера могут иметь иные причины. Параметр client-output-buffer-limit replica относится к данному классу клиента и не должно путаться с repl-backlog-size считаться равнозначными. Прежде чем изменять ограничения, проверьте журналы, документацию по версиям и возможные последствия для других подключений.

Почему наличие большого запаса заказов ещё не гарантирует высокую доступность

Буфер улучшает восстановление связи, но не делает асинхронную репликацию, реализуемую по умолчанию, без потерь. Первичный сервер может подтвердить операцию записи клиенту ещё до того, как реплика её обработает. Если в этот промежуток времени первичный сервер выйдет из строя, соответствующая операция может отсутствовать на выбранной позже резервной системе. Один лишь размер буфера не устраняет эту проблему Риск потери данных при переключении на резервный сервер не.

Также WAIT не превращает топологию Redis в систему с гарантированной сильной согласованностью. Команда может ожидать подтверждений от реплик; фактическая безопасность данных по-прежнему зависит от других факторов, в частности от поведения механизмов сохранения данных и переключения при сбое. Аналогичным образом ограничивают min-replicas-to-write и min-replicas-max-lag принимать новые операции записи в соответствии со своими условиями, не сохраняя автоматически каждую отдельную операцию на постоянной основе в нескольких экземплярах.

Для Высокая доступность Поэтому вам необходимо принять комплексную решение: допустимая потеря данных, допустимое время простоя, сохранность данных, обнаружение сбоев, выбор нового первичного сервера и восстановление. При этом Sentinel или Redis Cluster могут выполнять другие задачи, отличные от задач бэклога. Если просто увеличить размер буфера, оставив все остальные допущения без изменений, это ещё не будет надёжным планом возобновления работы.

Тестирование изменений и выявление повторяющихся проблем

Начните контролируемое тестирование в изолированной среде с аналогичной версией Redis и предсказуемой нагрузкой на запись. Перед прерыванием запишите идентификаторы репликации, смещения, заполненность списка ожидающих операций и объем используемой памяти. Затем имитируйте кратковременное прерывание соединения, не внося изменений в производственные брандмауэры или процессы без предварительной проверки. После восстановления соединения наблюдайте, происходит ли частичная или полная синхронизация и сколько времени занимает наверстывание.

В каждом эксперименте по возможности изменяйте только один значимый параметр. Если одновременно меняются бэклог, нагрузка на запись и условия сети, то определить, что именно повлияло на результат, будет практически невозможно. Повторите эксперимент с различной продолжительностью прерывания и разными фазами нагрузки. Таким образом, на основе одного успешного восстановления соединения можно сформировать обоснованную оценку поведения системы. Наблюдаемые ограничения следует документировать, не рассматривая их как гарантию для каждого будущего сбоя.

При повторных полных синхронизациях сначала проверь, совместима ли история данных вообще. Затем обратите внимание на оставшиеся байты, время отсутствия реплики, указания на перезапуски и фактическую скорость наверстывания. Слишком маленький буфер — одна из возможных причин, но не единственная. Особенно важно различать слишком длительный разовый пробел и ситуацию, когда реплика постоянно отстаёт даже при наличии подключения.

В конечном итоге правильная настройка — это та, которая покрывает заданное окно простоя при реалистичной нагрузке и оставляет достаточно памяти для остальной части работы. Обязательно фиксируйте вместе основу измерений, источник конфигурации и дату проверки. После значительных изменений в характере записи, топологии или версии Redis расчёты необходимо перепроверить. Благодаря этому бэклог остаётся обоснованным операционным решением, а не просто цифрой, принятой однажды и навсегда.