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

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.