Техническое обслуживание в 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-postgresql.maintenanceTask.viewer или выше.
Чтобы управлять заданиями на техническое обслуживание, необходима роль managed-postgresql.maintenanceTask.editor или выше.
Порядок обслуживания
В однохостовых кластерах Managed Service for PostgreSQL техническое обслуживание проходит хост-мастер. Поэтому если во время технического обслуживания потребуется перезагрузка мастера, такой кластер станет недоступным.
В многохостовых кластерах техническое обслуживание проводится в следующем порядке:
-
Хосты-реплики последовательно проходят техническое обслуживание. Порядок реплик в очереди определяется случайным образом. Если во время технического обслуживания потребуется перезагрузка реплики, она станет недоступной на это время.
-
Мастер проходит техническое обслуживание и получает обновления. Если во время технического обслуживания потребуется перезагрузка мастера и он станет недоступным, его роль возьмет на себя одна из реплик.
Если вы используете для доступа к кластеру FQDN хоста-мастера, такой кластер может стать недоступным. Чтобы обеспечить бесперебойную работу приложения, при подключении к кластеру перечислите все хосты и укажите параметр
target_session_attrs. Подробнее.
Подробнее об операциях во время обслуживания:
| Операция | Когда применяется | Что происходит | Влияние на приложение |
|---|---|---|---|
| Перезапуск (Restart) | Минорное обновление PostgreSQL, обновление системных библиотек | Каждый узел кластера поочередно останавливается и запускается. Процесс PostgreSQL перезапускается на каждом узле. | Происходит кратковременный разрыв соединений на время остановки и старта процесса PostgreSQL на всех хостах. В зависимости от нагрузки это может длиться от нескольких секунд до минут. Чтобы минимизировать это время, мы выполняем чекпоинт непосредственно перед перезапуском. Операции на запись, не успевшие завершиться, будут прерваны. |
| Переключение мастера (Switchover) | Обновления, требующие перезагрузки сервера | Каждый узел кластера поочередно останавливается и перезагружается. Если это текущий мастер, то одна из реплик получает статус нового мастера. | Происходит разрыв соединений. Переключение происходит быстрее полной перезагрузки сервера. Приложение должно быть готово к кратковременному переходу кластера в режим «только чтение» и поиску мастера. |
| Принудительное обновление версии | Мажорное обновление кластеров на неподдерживаемых версиях | Мастер останавливается, обновляется и остается выключенным. Поочередно отключаются и обновляются реплики. После обновления реплики возвращаются в работу в режиме чтения. После обновления всех реплик возвращается мастер. | Происходит разрыв соединений на время установки обновления. Рекомендуется самостоятельно планировать обновление версии кластера до завершения ее жизненного цикла. |
Влияние обслуживания на кластер
В зависимости от типа сервисных работ возможно влияние на кластер:
- нет влияния на пользователей БД или влияние будет минимальным;
- текущие соединения с БД будут разорваны, клиентам нужно установить соединение заново;
- кластер на некоторое время будет доступен только для чтения;
- из-за перезагрузки хоста-мастера произойдет переключение хоста-мастера на одну из реплик;
- в кластере произойдет смена хоста-мастера, во время которой БД будет доступна только для чтения.
У сервисных работ есть прогнозируемая продолжительность и прогнозируемая дата окончания. Они вычисляются на основе статистики времени выполнения подобных задач в прошлом. Полученные данные могут быть неточными и зависят от вашего кластера.