Техническое обслуживание в Managed Service for PostgreSQL

Под техническим обслуживанием в Managed Service for PostgreSQL понимается:

• установки минорных обновлений и исправлений безопасности СУБД, пуллера соединений;
• обновление хостовой операционной системы и другого служебного ПО;
• плановое автоматическое увеличение размера хранилища;
• другие сервисные работы.

Изменение мажорной версии СУБД не включено в техническое обслуживание. Подробнее о переходе между мажорными версиями см. в разделе Обновление версии PostgreSQL.

Окно обслуживанияОкно обслуживания

Предпочтительное время начала технического обслуживания можно задать с помощью интерфейсов Yandex Cloud (консоль управления, CLI, Terraform и API) при создании кластера или изменении его настроек:

• Вариант В любое время (по умолчанию) разрешает проводить техническое обслуживание в любое время.
• Вариант По расписанию позволяет выбрать день недели и время по UTC, когда будет проводиться техническое обслуживание. Например, можно выбрать время, когда кластер наименее загружен.

В консоли управления время начала обслуживания выбирается в виде часового интервала. В других интерфейсах задается порядковый номер этого интервала от 1 до 24.

Например, чтобы начать обслуживание с 00:00 до 01:00, укажите 1, а с 04:00 до 05:00 — 5.

Порядок обслуживанияПорядок обслуживания

В однохостовых кластерах Managed Service for PostgreSQL техническое обслуживание проходит хост-мастер. Поэтому если во время технического обслуживания потребуется перезагрузка мастера, такой кластер станет недоступным.

В многохостовых кластерах техническое обслуживание проводится в следующем порядке:

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

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

   Если вы используете для доступа к кластеру FQDN хоста-мастера, такой кластер может стать недоступным. Чтобы обеспечить бесперебойную работу приложения, при подключении к кластеру перечислите все хосты и укажите параметр target_session_attrs. Подробнее.

Влияние обслуживания на кластерВлияние обслуживания на кластер

В зависимости от типа сервисных работ возможно влияние на кластер:

• нет влияния на пользователей БД или влияние будет минимальным;
• текущие соединения с БД будут разорваны, клиентам нужно установить соединение заново;
• кластер на некоторое время будет доступен только для чтения;
• кластер на некоторое время будет полностью недоступен в связи с перезагрузкой;
• в кластере происходит смена хоста-мастера — БД будет доступна только для чтения.