Репликация и отказоустойчивость
Managed Service for Redis использует стандартную репликацию Redis и реализует высокую доступность данных в кластере с помощью Redis Sentinel.
Репликация
В кластерах Managed Service for Redis используется асинхронная репликация: результат запроса на запись информации отражается на хосте-мастере, который после этого отправляет данные на реплики кластера. Процесс репликации никак не отражается на доступности мастера, но может прерывать доступность реплик при загрузке новых данных в память (до нескольких секунд для больших баз данных).
Из-за асинхронности репликации данные на репликах могут быть неактуальными: пока реплика обрабатывает обновления, полученные от мастера, она продолжает отвечать на запросы уже имеющимися данными (выставлен параметр replica-serve-stale-data yes).
Из-за ограниченных ресурсов хосты классов b1, b2 и b3 не реплицируются.
Подробнее о том, как организована репликация в Redis, читайте в документации СУБД.
Отказоустойчивость
Хост-мастер может быть сменен не только автоматически в результате сбоя, но и вручную. Ручное переключение мастера доступно как для шардированного кластера, так и для нешардированного.
Высокая доступность данных в кластере без шардирования реализована с помощью Redis Sentinel: в кластере из как минимум 3 хостов сервисы Sentinel автоматически управляют выбором мастера и конфигурацией реплик.
Чтобы принимать решения о работе кластера, необходима работоспособность большинства сервисов Sentinel. Поэтому используя Managed Service for Redis, экономичнее разворачивать кластеры с нечетным количеством хостов. Например, кластер с 3 хостами может потерять 1 хост и продолжить работу, но кластер с 4 хостами также может потерять не более 1 хоста — при потере второго хоста оставшихся экземпляров Sentinel не хватит, чтобы выбрать новый мастер.
Кластер из 2 хостов не обеспечивает полной отказоустойчивости по той же причине: одного из двух экземпляров Sentinel не хватит для того, чтобы назначить один хост мастером, если другой отказал. В этой ситуации кластер может обрабатывать только операции чтения.
Владельцу кластера Managed Service for Redis недоступна настройка сервисов Sentinel, но доступно чтение предоставляемой ими информации. Подробнее о Sentinel читайте в документации СУБД.
Назначение мастером другого хоста при выходе из строя основного мастера
Если хост-мастер выйдет из строя, то новым мастером станет любой из хостов кластера, доступных для репликации. Если для хостов задан приоритет назначения мастером, то новым мастером станет хост с наименьшим приоритетом. Минимальное значение — 0
, максимальное значение и значение по умолчанию — 100
. Хост с приоритетом 0
никогда не будет выбран в качестве мастера.
Персистентность
В кластерах Managed Service for Redis используются предустановленные настройки персистентности данных. При желании персистентность можно отключить — это увеличит пропускную способность сервера, поскольку СУБД перестанет записывать изменения на диск.
Важно
Отключайте персистентность, только если для работы вашего приложения не важна сохранность данных, например при использовании Managed Service for Redis в качестве кэша. В таком случае последние записанные в 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) выключен.