Репликация и отказоустойчивость

Yandex Managed Service for Valkey™ использует стандартную репликацию Valkey™ и реализует высокую доступность данных в кластере с помощью агента управления состоянием хоста rdsync.

РепликацияРепликация

В кластерах Yandex Managed Service for Valkey™ используется асинхронная репликация: результат запроса на запись информации отражается на хосте-мастере, который после этого отправляет данные на реплики кластера. Процесс репликации никак не отражается на доступности мастера, но может прерывать доступность реплик при загрузке новых данных в память (до нескольких секунд для больших баз данных).

Из-за асинхронности репликации данные на репликах могут быть неактуальными: пока реплика обрабатывает обновления, полученные от мастера, она продолжает отвечать на запросы уже имеющимися данными (выставлен параметр replica-serve-stale-data yes).

Из-за ограниченных ресурсов хосты классов b1, b2 и b3 не реплицируются.

Подробнее о том, как организована репликация в Valkey™, читайте в документации СУБД.

ОтказоустойчивостьОтказоустойчивость

Для обеспечения отказоустойчивости в архитектуру Yandex Managed Service for Valkey™ интегрирован агент управления состоянием хоста rdsync, разработанный Яндексом.

Состояние хоста хранится в распределенной системе управления конфигурацией. При потере соединения с хранилищем DCS (Distributed Configuration Store, например, ZooKeeper, etcd, Consul) агент переводит хост в режим protected mode, а клиентские соединения разрываются. Если для хоста-реплики с наибольшим приоритетом требуется полная ресинхронизация данных, при выборе нового мастера агент останавливает репликацию и выбирает хост с наименьшим отставанием от мастера.

Благодаря агенту rdsync в кластере Yandex Managed Service for Valkey™:

• Конфигурации из четного числа хостов (если кластер нешардированный) или одного-двух шардов (если кластер шардированный) являются отказоустойчивыми.

• Обработка клиентского запроса имени хоста, доступного для записи, работает согласованно с агентом rdsync и выдает актуальную информацию клиентам, т. к. состояние всех хостов известно.

• Снижается вероятность потери данных при использовании WAIT с числом доступных реплик N/2, где N – число хостов в кластере.

Шардированные кластеры с типом диска local-ssd, в которых на каждый шард приходится только один хост, не считаются отказоустойчивыми. Создать такой кластер нельзя.

Назначение мастером другого хоста при выходе из строя основного мастераНазначение мастером другого хоста при выходе из строя основного мастера

Если хост-мастер выйдет из строя, то новым мастером станет хост с наименьшим отставанием от мастера.

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

Задать приоритет хоста можно:

• при создании кластера или хоста в кластере;
• при изменении настроек хоста.

Минимальное значение (наименьший приоритет) — 0. Хост с таким приоритетом может стать мастером, только если нет других подходящих на роль мастера хостов. Значение приоритета по умолчанию — 100. Возможен ввод значения больше 100.

Хост-мастер может быть сменен не только автоматически в результате сбоя, но и вручную. Ручное переключение мастера доступно как для шардированного кластера, так и для нешардированного.

ПерсистентностьПерсистентность

В кластерах Yandex Managed Service for Valkey™ используются предустановленные настройки персистентности данных. При желании персистентность можно отключить — это увеличит пропускную способность сервера, поскольку СУБД перестанет записывать изменения на диск.

Настройки персистентностиНастройки персистентности

По умолчанию персистентность в кластере включена и использует следующие настройки Valkey™:

• save ""

  Регулярное сохранение RDB-файла отключено. Вместо этого используется режим AOF.

• appendonly yes

  Включен режим AOF (Append Only File). В этом режиме Valkey™ фиксирует в логе каждую новую операцию записи, при этом уже записанные данные не изменяются.

• no-appendfsync-on-rewrite yes

  Так как политика AOF fsync установлена на everysec, процесс фонового сохранения BGSAVE или фоновой перезаписи BGREWRITEAOF журнала AOF выполняет много операций ввода-вывода на диске. Valkey™ может слишком долго блокировать вызов fsync() в некоторых конфигурациях Linux.

  Настройка предотвращает вызов fsync() в основном процессе системы во время выполнения BGSAVE или BGREWRITEAOF.

  Когда выполняется BGREWRITEAOF, работает fsync(). Valkey™ записывает самую короткую последовательность команд, необходимую для восстановления текущего набора данных в памяти. Размер данных регулируется настройкой aof-rewrite-incremental-fsync.

• auto-aof-rewrite-percentage 100

  Размер файла логов AOF должен быть превышен на 100%, чтобы сработала перезапись. Учитывает настройку auto-aof-rewrite-min-size файла логов.

• auto-aof-rewrite-min-size 64mb

  Минимальный размер, при котором начнется процесс перезаписи файла AOF, равен 64 мегабайтам.

• aof-load-truncated yes

  Разрешена загрузка усеченного файла AOF после выхода системы из строя. Уведомление о загрузке усеченного файла выводится в лог.

• aof-rewrite-incremental-fsync yes

  Включена синхронизация файла AOF через каждые 32 мегабайта сгенерированных данных.

• aof-use-rdb-preamble yes

  Включено использование RDB-файла в качестве префикса в начале файла AOF при перезаписи или восстановлении.

Подробнее о механизмах обеспечения персистентности Valkey™ читайте в документации СУБД и в описании конфигурационного файла valkey.conf.

Отключение персистентностиОтключение персистентности

С отключенной персистентностью действуют следующие настройки Valkey™:

• save ""

  Регулярное сохранение RDB-файла отключено.

• appendonly no

  Режим AOF (Append Only File) выключен.