Yandex Cloud
  • Сервисы
  • Решения
  • Почему Yandex Cloud
  • Сообщество
  • Тарифы
  • Документация
  • Связаться с нами
Подключиться
Language / Region
Проект Яндекса
© 2023 ООО «Яндекс.Облако»
Yandex Managed Service for Redis
  • Начало работы
  • Пошаговые инструкции
    • Все инструкции
    • Информация об имеющихся кластерах
    • Создание кластера
    • Изменение настроек кластера и базы данных
    • Подключение к базе данных
      • Подготовка к подключению
      • Подключение к нешардированному кластеру
      • Подключение к шардированному кластеру
    • Остановка и запуск кластера
    • Обновление версии Redis
    • Управление хостами кластера
    • Управление шардами
    • Управление резервными копиями
    • Переключение мастера
    • Мониторинг состояния кластера и хостов
    • Просмотр логов кластера
    • Удаление кластера
  • Практические руководства
    • Все сценарии
    • Хранение сессий PHP в Managed Service for Redis
    • Миграция базы данных в Managed Service for Redis
  • Концепции
    • Взаимосвязь ресурсов сервиса
    • Классы хостов
    • Сеть в Managed Service for Redis
    • Шардирование
    • Резервные копии
    • Репликация и отказоустойчивость
    • Поддерживаемые клиенты
    • Управление памятью в Managed Service for Redis
    • Доступные команды Managed Service for Redis
    • Квоты и лимиты
    • Типы диска
    • Техническое обслуживание
    • Настройки Redis
  • Управление доступом
  • Правила тарификации
    • Действующие правила
    • Архив
      • До 1 февраля 2020 года
  • Справочник API
    • Аутентификация в API
    • gRPC (англ.)
      • Overview
      • BackupService
      • ClusterService
      • ResourcePresetService
      • OperationService
    • REST (англ.)
      • Overview
      • Backup
        • Overview
        • get
        • list
      • Cluster
        • Overview
        • addHosts
        • addShard
        • backup
        • create
        • delete
        • deleteHosts
        • deleteShard
        • get
        • getShard
        • list
        • listBackups
        • listHosts
        • listLogs
        • listOperations
        • listShards
        • move
        • rebalance
        • rescheduleMaintenance
        • restore
        • start
        • startFailover
        • stop
        • streamLogs
        • update
        • updateHosts
      • ResourcePreset
        • Overview
        • get
        • list
      • Operation
        • Overview
        • get
  • История изменений
  • Вопросы и ответы
    • Общие вопросы
  1. Концепции
  2. Репликация и отказоустойчивость

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

Статья создана
Yandex Cloud
,
улучшена
Anton P.
  • Репликация
  • Отказоустойчивость
    • Назначение мастером другого хоста при выходе из строя основного мастера
  • Персистентность
    • Настройки персистентности
    • Отключение персистентности

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) выключен.

Была ли статья полезна?

Language / Region
Проект Яндекса
© 2023 ООО «Яндекс.Облако»
В этой статье:
  • Репликация
  • Отказоустойчивость
  • Назначение мастером другого хоста при выходе из строя основного мастера
  • Персистентность
  • Настройки персистентности
  • Отключение персистентности