[Документация Yandex Cloud](../../index.md) > [Yandex StoreDoc](../index.md) > [Концепции](index.md) > Высокая доступность кластера

# Высокая доступность кластера Yandex StoreDoc

На высокую доступность кластера Yandex StoreDoc влияют параметры, относящиеся к [SLA](https://yandex.ru/legal/cloud_sla_mdb/), а также некоторые другие настройки.

## Количество и расположение хостов кластера {#host-configuration}

### Для нешардированного кластера

Кластер из одного хоста не обеспечивает высокую доступность. При выходе из строя первичной реплики кластер будет недоступен на чтение и запись до восстановления ее работы.

Если кластер содержит хотя бы два хоста, он обеспечивает доступность при выходе из строя одного из них.


Скрытые хосты не влияют на доступность кластера и не учитываются в расчетах.

### Для кластера со стандартным шардированием


Кластер устойчив к отказу одного хоста при выполнении следующих условий:
* Кластер содержит хотя бы два хоста `MONGOINFRA`.
* Каждый шард кластера содержит хотя бы два хоста `MONGOD`.


Скрытые хосты не влияют на доступность кластера и не учитываются в расчетах.

### Для кластера с расширенным шардированием


Кластер устойчив к отказу одного хоста при выполнении следующих условий:
* Кластер содержит хотя бы два хоста `MONGOS` и два хоста `MONGOCFG`.
* Каждый шард кластера содержит хотя бы два хоста `MONGOD`.


Скрытые хосты не влияют на доступность кластера и не учитываются в расчетах.

## Резервное копирование {#backup}

Если кластер вышел из строя, его можно восстановить из [резервной копии](backup.md).

Чтобы обеспечить сохранность данных и допустимое время восстановления кластера:
* Убедитесь, что в [заданный момент начала резервного копирования](../operations/update.md#change-additional-settings) кластер работает и автоматические резервные копии создаются.
* Установите подходящий [срок хранения резервных копий](backup.md#storage).
* Перед важными изменениями проводите ручное резервное копирование. Созданные вручную резервные копии хранятся бессрочно.
* Проводите регулярные тесты восстановления кластера из резервных копий.

## Подключение к Yandex StoreDoc {#connect}

На доступность кластера Yandex StoreDoc влияют способ и настройки подключения:
* Используйте для подключения только [рекомендованные клиенты](supported-clients.md).
* Включите [публичный доступ](network.md#Public-access-to-host) и [настройте группы безопасности](network.md#security-groups) для каждого хоста кластера.

  {% note warning %}

  Если публичный доступ настроен не для всех хостов кластера, [автоматическая смена первичной реплики](replication.md) может сделать кластер недоступным из интернета.

  {% endnote %}

* Не рекомендуется изменять значение параметра `writeConcern` при выполнении запроса.
  
  По умолчанию для всех операций записи используется значение `writeConcern: { w: "majority" }` — операция считается успешной, когда ее подтвердило большинство реплик. При запросах с  `writeConcern: 1` данные на вторичных репликах могут отставать. Пока данные на репликах не синхронизируются с мастером, новые операции записи со значением `writeConcern: { w: "majority" }` или без указания настройки `writeConcern` будут завершаться таймаутом. Операции на запись с `writeConcern: 1` будут выполняться в асинхронном режиме, но каждая операция будет увеличивать отставание данных на вторичных репликах. При выходе из строя мастера несохраненные на репликах данные будут потеряны. Поэтому для таких кластеров не гарантируются SLA и высокая доступность.

## Свободное место в хранилище {#storage-settings}

Yandex StoreDoc отслеживает расходование дискового пространства и автоматически переводит в режим **Только чтение** те хосты кластера, у которых:
* осталось менее 500 МБ свободного места (если размер хранилища хоста менее 600 ГБ);
* осталось менее 5 ГБ свободного места (если размер хранилища хоста 600 ГБ или более).

Чтобы хосты кластера оставались доступными на запись, регулярно [проверяйте график Disk space usage per host](../operations/monitoring.md#cluster) или [создайте алерт с метрикой disk.free_bytes](../operations/monitoring.md#monitoring-integration).

## Тип виртуальной машины {#vm-type}

На доступность кластера влияет тип виртуальных машин, на которых будут развернуты хосты. Высокодоступный кластер должен иметь тип ВМ с гарантированной долей vCPU 100%. Тип ВМ **burstable** с гарантированной долей vCPU 50% не обеспечивает высокой доступности и должен использоваться только для тестовых окружений.

## Обслуживание кластера и изменение его параметров {#maintenance}

Следующие операции могут привести к прерыванию соединений с БД и временному снижению производительности:
* Запуск [технического обслуживания](maintenance.md) (вы можете задать предпочтительное время запуска, настроив [окно обслуживания](maintenance.md#maintenance-window)).
* [Изменение класса хостов](../operations/update.md#change-resource-preset).
* Автоматическое и ручное [резервное копирование](backup.md) баз данных.

Проводите эти операции в моменты минимальной нагрузки на кластер. Выбирайте предпочтительный [день недели и время обслуживания](maintenance.md#maintenance-window) с учетом предполагаемой нагрузки на кластер.

{% note warning %}

Во время проведения этих операций возможна смена первичной реплики. Если в кластере нет хостов, которые могли бы стать новой первичной репликой, кластер будет временно недоступен.

{% endnote %}