Высокая доступность
В Managed Postgres доступны различные уровни высокой доступности в соответствии с вашими требованиями к надежности и производительности. Вы можете добавить одну или две резервные реплики при создании базы данных или при необходимости позже изменить эту конфигурацию на странице Settings.
Варианты высокой доступности
2 Standbys
При использовании двух резервных узлов рядом с основным создаются два узла-реплики. Оба резервных узла имеют тот же размер, что и основной, и любой из них может взять на себя нагрузку в случае отказа основного.
По умолчанию эта конфигурация использует синхронную репликацию, при которой основной узел ожидает подтверждения как минимум от одного резервного узла перед подтверждением записи. Это обеспечивает более сильные гарантии сохранности данных по сравнению с асинхронной репликацией. Поскольку требуется только одно подтверждение (а не оба), влияние на производительность менее существенно, чем при синхронной репликации с одним резервным узлом.
Если для вас приоритетнее более высокая производительность записи, чем дополнительные гарантии сохранности данных, вы можете переключиться на асинхронную репликацию.
1 Standby
При использовании одного standby рядом с вашим primary разворачивается узел‑реплика. Standby имеет тот же размер, что и primary, и находится в режиме ожидания, чтобы при отказе primary немедленно принять его роль.
По умолчанию данные реплицируются на standby с помощью асинхронной репликации. Это означает, что операции записи подтверждаются на primary, не дожидаясь подтверждения от standby. Асинхронная репликация обеспечивает высокую доступность, не замедляя операции записи из‑за дополнительной сетевой задержки. Однако это также означает, что на момент отказа primary standby может не содержать самые последние транзакции.
Для большинства приложений такой компромисс между производительностью и небольшим риском потери совсем недавних записей оправдан. Если вашему приложению требуются более строгие гарантии надежного сохранения данных, вы можете включить синхронную репликацию, хотя это и добавит задержку к операциям записи.
Без Standby
В этом варианте создаётся только основной узел выбранного размера. Standby-узел не создаётся. Основной узел по‑прежнему отслеживается на предмет сбоев, но восстановление может занять больше времени в зависимости от характера проблемы, поскольку нет реплики, готовой принять нагрузку.
Эта конфигурация лучше всего подходит для сред разработки, тестирования или некритичных рабочих нагрузок, где допустим некоторый простой.
Standbys и read replicas
Standbys и read replicas выполняют разные задачи в Managed Postgres и настраиваются отдельно.
Standbys предназначены исключительно для обеспечения высокой доступности и автоматического failover. Они реплицируют данные с primary с помощью streaming replication и всегда готовы быть повышены до роли primary в случае его отказа. Standbys не доступны для выполнения запросов на чтение.
Read replicas предназначены для масштабирования чтения. Они извлекают данные WAL (Write-Ahead Log) из объектного хранилища и работают в отдельном сетевом окружении со своей собственной конечной точкой подключения. Read replicas позволяют перенести нагрузку на операции чтения с вашего primary, не затрагивая гарантии HA.
Почему резервные серверы не обслуживают запросы на чтение
Хотя некоторые провайдеры баз данных предоставляют горячие резервные серверы для запросов только на чтение, Managed Postgres сознательно этого не делает. Разрешение выполнения запросов на чтение на резервных серверах может подорвать их основную задачу: быть готовыми немедленно взять на себя роль primary при его отказе.
Есть две основные проблемы:
-
Конкуренция с WAL replay: При нагрузках с интенсивной записью запросы на чтение на резервном сервере конкурируют с WAL replay за системные ресурсы. Такая конкуренция может вызывать высокий лаг репликации, из-за чего резервный сервер отстает от primary. Если произойдет failover, пока резервный сервер отстает, у него не будет самых свежих данных, и он может быть не готов корректно принять роль primary.
-
Помехи работе VACUUM: Долго выполняющиеся запросы на чтение на резервном сервере могут мешать
VACUUM(иAUTOVACUUM) очищать «мертвые» кортежи на primary. PostgreSQL не может удалять строки, к которым активный запрос на любой реплике все еще может обращаться. Это может приводить к раздуванию таблиц и деградации производительности со временем.
Используя резервные серверы исключительно для задач failover, Managed Postgres обеспечивает, что они всегда синхронизированы и готовы взять на себя нагрузку с минимальной потерей данных и простоем. Для масштабирования чтения используйте вместо этого реплики для чтения.
Обработка сбоев
Все управляемые экземпляры Postgres находятся под непрерывным мониторингом на предмет сбоев, независимо от того, включена ли высокая доступность. Во всех случаях система пытается автоматически восстановиться после сбоев.
Когда доступны резервные реплики (standby), автоматическое восстановление происходит быстрее и проще. Обычно система восстанавливается в течение нескольких минут за счёт повышения резервной реплики до primary. Без резервных реплик восстановление может потребовать ручного вмешательства, что значительно увеличивает длительность любого простоя.
