[Документация Yandex Cloud](../../index.md) > [Yandex Managed Service for Valkey™](../index.md) > [Концепции](index.md) > Репликация и персистентность

# Репликация и персистентность в Yandex Managed Service for Valkey™

Yandex Managed Service for Valkey™ использует стандартную репликацию Valkey™ совместно с агентом управления состоянием хоста [rdsync](https://github.com/yandex/rdsync), а также предустановленные настройки персистентности данных.

## Репликация {#replication}

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

Из-за асинхронности репликации данные на репликах могут быть неактуальными: пока реплика обрабатывает обновления, полученные от мастера, она продолжает отвечать на запросы уже имеющимися данными (выставлен параметр [replica-serve-stale-data yes](https://github.com/valkey-io/valkey/blob/unstable/valkey.conf)).

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

Подробнее о том, как организована репликация в Valkey™, читайте в [документации СУБД](https://valkey.io/topics/replication/).

### Агент управления состоянием хоста rdsync {#rdsync}

В архитектуру Yandex Managed Service for Valkey™ интегрирован агент управления состоянием хоста [rdsync](https://github.com/yandex/rdsync), разработанный Яндексом.

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

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

* Обработка [клиентского запроса](https://valkey.io/topics/sentinel-clients/) имени хоста, доступного для записи, работает согласованно с агентом `rdsync` и выдает актуальную информацию клиентам, т. к. состояние всех хостов известно.

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

{% note info %}

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

{% endnote %}

### Назначение мастером другого хоста при выходе из строя основного мастера {#master-failover}

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

Повлиять на выбор мастера в кластере Valkey™ можно с помощью [настройки приоритетов](../operations/hosts.md#update) для хостов кластера. Новым мастером станет хост с наибольшим приоритетом. Если для хоста-реплики с наибольшим приоритетом требуется полная ресинхронизация данных, то значение приоритета будет проигнорировано, а новым мастером станет хост с наименьшим отставанием от мастера.

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

* при [создании кластера](../operations/cluster-create.md) или [хоста в кластере](../operations/hosts.md#add);
* при [изменении настроек хоста](../operations/hosts.md#update).

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

Хост-мастер может быть сменен не только автоматически в результате сбоя, но и [вручную](../operations/failover.md).

## Персистентность {#persistence}

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

{% note warning %}

Отключайте персистентность только если для работы вашего приложения не важна сохранность данных, например при использовании Yandex Managed Service for Valkey™ в качестве кеша. В таком случае последние записанные в Valkey™ данные будут храниться только в оперативной памяти и могут быть утеряны при аварийном завершении работы сервера.

{% endnote %}

Персистентность также можно включить только для реплик. В этом случае пропускная способность сервера увеличится, но риск потери данных уменьшится.

### Включение персистентности {#persistence-on}

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

* **save ""**{#setting-save-rdb}

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

* **appendonly yes**{#setting-appendonly}

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

* **no-appendfsync-on-rewrite yes**{#setting-no-appendfsync}

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

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

  Когда выполняется `BGREWRITEAOF`, работает `fsync()`. Valkey™ записывает самую короткую последовательность команд, необходимую для восстановления текущего набора данных в памяти. Размер данных регулируется настройкой [aof-rewrite-incremental-fsync](#setting-rewrite-incremental).

* **auto-aof-rewrite-percentage 100**{#setting-rewrite-percentage}

  Размер файла логов AOF должен быть превышен на 100%, чтобы сработала перезапись. Учитывает настройку [**auto-aof-rewrite-min-size**](#setting-rewrite-size) файла логов.

* **auto-aof-rewrite-min-size 64mb**{#setting-rewrite-size}

  Минимальный размер, при котором начнется процесс перезаписи файла AOF, равен 64 мегабайтам.

* **aof-load-truncated yes**{#setting-load-truncated}

  Разрешена загрузка усеченного файла AOF после выхода системы из строя. Уведомление о загрузке усеченного файла выводится в лог.  

* **aof-rewrite-incremental-fsync yes**{#setting-rewrite-incremental}

  Включена синхронизация файла AOF через каждые 4 мегабайта сгенерированных данных.

* **aof-use-rdb-preamble yes**{#setting-rdb-preamble}

  Включено использование RDB-файла в качестве префикса в начале файла AOF при перезаписи или восстановлении.

Подробнее о механизмах обеспечения персистентности Valkey™ читайте в [документации СУБД](https://valkey.io/topics/persistence) и в описании конфигурационного файла [valkey.conf](https://github.com/valkey-io/valkey/blob/unstable/valkey.conf).

### Отключение персистентности {#persistence-off}

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

* **save ""**

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

* **appendonly no**

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

### Включение персистентности только на репликах {#persistence-on-replicas}

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

* На репликах — как при включенной персистентности.

* На мастере — как при выключенной персистентности.

Если роли хостов меняются, настройки обновляются автоматически.