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