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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• save ""

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

• appendonly yes

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

• no-appendfsync-on-rewrite yes

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

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

  Когда выполняется BGREWRITEAOF, работает fsync(). Redis записывает самую короткую последовательность команд, необходимую для восстановления текущего набора данных в памяти. Размер данных регулируется настройкой 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 при перезаписи или восстановлении.

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

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

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

• save ""

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

• appendonly no

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