Ограничения на гибком сервере База данных Azure для PostgreSQL

В следующих разделах описываются ограничения емкости и функциональные ограничения для База данных Azure для PostgreSQL гибких серверов. Сведения о уровнях ресурсов для вычислений, памяти и хранилища см. в статьях по вычислениям и хранилищу .

Максимальное количество соединений

В следующей таблице показано максимальное количество подключений по умолчанию для каждой ценовой категории и конфигурации виртуальных ядер. Гибкий сервер База данных Azure для PostgreSQL резервирует 15 подключений для физической репликации и мониторинга гибкого сервера База данных Azure для PostgreSQL. Таким образом, таблица уменьшает значение максимального количества подключений пользователей на 15 от общего максимального числа подключений.

Зарезервированные слоты подключения, число которых на данный момент составляет 15, могут измениться. Рекомендуем регулярно проверять общее количество зарезервированных подключений на сервере. Вычислите это число путем суммирования значений reserved_connections и superuser_reserved_connections параметров. Максимальное количество доступных подключений пользователей — max_connections (reserved_connections + superuser_reserved_connections).

Система рассчитывает значение по умолчанию для параметра max_connections при подготовке к работе экземпляра гибкого сервера База данных Azure для PostgreSQL на основе названия продукта, который вы выбираете для его вычислительных ресурсов. Любые последующие изменения выбора продукта для вычислительных ресурсов, которые поддерживают этот экземпляр, не повлияют на значение по умолчанию параметра max_connections для этого экземпляра. Мы рекомендуем, чтобы при каждом изменении продукта, назначенного экземпляру, вы также корректировали значение параметра max_connections в соответствии со значениями в приведённой выше таблице.

Изменение значения параметра max_connections

При настройке База данных Azure для PostgreSQL гибкого сервера он автоматически определяет наибольшее количество одновременных подключений, которые он может обрабатывать. Конфигурация сервера определяет это число, и вы не можете изменить его.

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

Если подключения превышают предел, может появиться следующая ошибка:

FATAL: sorry, too many clients already.

При использовании гибкого сервера База данных Azure для PostgreSQL для занятой базы данных с большим количеством одновременных подключений может возникнуть серьезная нагрузка на ресурсы. Эта нагрузка может привести к высокой загрузке ЦП, особенно при одновременном создании большого количества подключений и при наличии коротких длительности подключений (менее 60 секунд). Эти факторы могут негативно повлиять на общую производительность базы данных, увеличив время, затраченное на обработку подключений и отключений.

Каждое подключение к гибкому серверу База данных Azure для PostgreSQL, независимо от того, простаивает оно или активно, потребляет значительный объем ресурсов базы данных. Такое потребление ресурсов может привести к проблемам с производительностью не только из-за высокой загрузки ЦП, но и из-за конкуренции за доступ к диску и конкуренции блокировок. Дополнительные сведения см. в статье "Количество подключений к базам данных " в вики-сайте PostgreSQL. Дополнительные сведения см. в статье "Определение и решение производительности подключения" в Azure Postgres.

Функциональные ограничения

В следующих разделах перечислены рекомендации по тому, что такое и что не поддерживается для ваших База данных Azure для PostgreSQL гибких серверов.

Масштабирование операций

• В настоящее время для масштабирования хранилища сервера требуется перезапуск сервера.
• Масштабирование хранилища сервера возможно только шагами в два раза. См. раздел Хранилище для получения дополнительных сведений.
• Уменьшение размера хранилища сервера не поддерживается. Чтобы уменьшить объём хранилища, необходимо выполнить дамп и восстановление на новом гибком сервере База данных Azure для PostgreSQL.

Storage

• После настройки размера хранилища его нельзя уменьшить. Необходимо создать новый сервер с требуемым размером хранилища, выполнить операцию дампа вручную и восстановления и перенести базы данных на новый сервер.
• Когда использование хранилища достигает 95% или если доступной емкости меньше 5 ГиБ (в зависимости от того, что больше), система автоматически переключает сервер на режим только для чтения , чтобы избежать ошибок, связанных с полным диском ситуаций. В редких случаях, если скорость роста данных опережает время, необходимое для перехода в режим только для чтения, сервер может по-прежнему выйти из хранилища. Вы можете включить автоматическое увеличение хранилища, чтобы избежать этих проблем и автоматически масштабировать хранилище на основе требований рабочей нагрузки.
• Мы рекомендуем настроить правила оповещений для storage used или storage percent при превышении ими определенных пороговых значений, чтобы вы могли заблаговременно принять меры, например увеличить размер хранилища. Например, можно задать оповещение, если процент хранения превышает 80 % использования.
• Если вы используете логическую репликацию, необходимо удалить слот логической репликации на основном сервере, если соответствующий подписчик больше не существует. В противном случае файлы журнала предзаписи (WAL) будут накапливаться на основном сервере и заполнять хранилище. Если хранилище превышает определенное пороговое значение и если слот логической репликации не используется (из-за недоступного подписчика), гибкий сервер База данных Azure для PostgreSQL автоматически удаляет неиспользуемый логический слот репликации. Это действие освобождает накопленные файлы WAL и предотвращает недоступность сервера, так как хранилище заполнено.
• Создание пространств таблиц не поддерживается. Если вы создаете базу данных, не укажите имя пространства таблиц. Гибкий сервер База данных Azure для PostgreSQL использует пространство таблиц по умолчанию, наследуемое базой данных шаблона. Небезопасно использовать табличное пространство, например временное, поскольку служба не может гарантировать, что такие объекты сохранятся после таких событий, как перезапуск сервера и переключение при отказе в конфигурации высокой доступности (HA).
• Потерянные файлы данных и несоответствия использования дисков. В редких случаях PostgreSQL может оставить потерянные файлы данных на диске. Эти файлы больше не имеют соответствующих записей в системном каталоге базы данных (который отслеживает все таблицы и данные). Это условие может произойти, если таблица создается и заполняется в транзакции, которая не завершается успешно (например, из-за сбоя или прерывания сервера), что приводит к несоответствию размера базы данных и фактическому использованию диска. Это поведение происходит из базы кода сообщества PostgreSQL и не зависит от Azure. Сообщество PostgreSQL знает о проблеме и изучает улучшения автоматической очистки в будущих выпусках. Дополнительные сведения см. в статье PostgreSQL: потерянные файлы в PostgreSQL. Это условие может привести к неожиданно высокому потреблению диска или хранилища.
  • Как обнаружить: Сравните размер, который сообщает база данных (с помощью таких SELECT pg_database_size('your_database')запросов), с метриками портала Azure для фактического использования диска. Если существует значительное несоответствие, потерянные файлы могут быть причиной. Если да:
    • Запустите VACUUM FULL в затронутых таблицах, чтобы освободить пространство (примечание. Это ресурсоемкое, требуется блокировка таблицы и может потребоваться простой).
    • Кроме того, используйте такие средства, как pg_repack или pg_squeeze, расширения для реорганизации без простоя, но сначала протестируйте в непроизводственной среде.
    • Наблюдайте через метрики портала Azure пороговые значения использования дисков. Если проблема сохраняется или вы не уверены, обратитесь в службу поддержки Azure для получения помощи.
  • Как предотвратить: Обеспечение правильного управления транзакциями в приложениях для минимизации неполных операций. Регулярно отслеживайте использование дисков с помощью метрик портала Azure. Обновление до последней поддерживаемой версии PostgreSQL может включать исправления сообщества для связанных проблем.

Нетворкинг

• В настоящее время мы не поддерживаем перемещение и выход из виртуальной сети.
• В настоящее время мы не поддерживаем объединение общедоступного доступа с развертыванием в виртуальной сети.
• Виртуальные сети не поддерживают правила брандмауэра. Вместо этого можно использовать группы безопасности сети.
• Серверы базы данных общедоступного доступа могут подключаться к общедоступному Интернету; например, через postgres_fdw. Вы не можете ограничить этот доступ. Серверы в виртуальных сетях могут иметь ограниченный исходящий доступ через группы безопасности сети.

Высокая доступность

• См. ограничения высокого уровня доступности.

Зоны доступности

• В настоящее время мы не поддерживаем ручное перемещение серверов в другую зону доступности. Однако, если использовать предпочтительную зону доступности в качестве зоны ожидания, можно включить режим высокой доступности. После того как вы настроите резервную зону, вы сможете переключиться на неё, а затем отключить HA.

Подсистема Postgres, расширения и PgBouncer

• Гибкий сервер База данных Azure для PostgreSQL поддерживает все функции подсистемы PostgreSQL, включая секционирование, логическую репликацию и внешние оболочки данных.
• Гибкий сервер База данных Azure для PostgreSQL поддерживает все contrib расширения и многое другое. Дополнительные сведения см. в разделе Расширения PostgreSQL.
• В настоящее время у серверов с возможностью увеличения производительности нет доступа к встроенному пулу подключений PgBouncer.

Операции остановки и запуска

• После остановки гибкого сервера База данных Azure для PostgreSQL он автоматически запускается через семь дней.

Запланированное обслуживание

• Настраиваемое время обслуживания можно изменить на любой день или время недели. Однако любые изменения, внесенные после получения уведомления об обслуживании, не будут влиять на следующее обслуживание. Изменения вступили в силу только со следующим ежемесячным запланированным обслуживанием.

Резервные копии сервера

• Система управляет резервными копиями. В настоящее время невозможно запускать резервные копии вручную. Вместо этого рекомендуется использовать pg_dump.

• Первый моментальный снимок — это полная резервная копия, а последовательные моментальные снимки — разностные резервные копии. Разностные резервные копии содержат только данные, изменённые с момента создания последней резервной копии снимка.

  Например, если размер базы данных составляет 40 ГБ, а подготовленное хранилище составляет 64 ГБ, первая резервная копия моментального снимка составляет 40 ГБ. Теперь, если вы измените 4 ГБ данных, размер следующей резервной копии на основе разностного моментального снимка составит всего 4 ГБ. Журналы транзакций (журналы упреждающей записи) хранятся отдельно от полных и разностных резервных копий и непрерывно архивируются.

Восстановление сервера

• При использовании функции восстановления на определенный момент времени система создает новый сервер с теми же конфигурациями вычислений и хранилищ, на которые он основан.
• Система восстанавливает серверы баз данных в виртуальных сетях в одни и те же виртуальные сети при восстановлении из резервной копии.
• На новом сервере, созданном во время восстановления, нет правил брандмауэра, которые были настроены на сервере-источнике. Необходимо создать правила брандмауэра отдельно для нового сервера.
• Мы не поддерживаем восстановление в другой подписке. В качестве обходного решения можно восстановить сервер в той же подписке, а затем перенести восстановленный сервер в другую подписку.

Безопасность

• PostgreSQL 14 и более поздних версиях отключено хэширование MD5, и системы создают хэши собственных паролей Postgres только с помощью метода SCRAM-SHA-256.

Связанный контент

• Параметры вычислений в Базе данных Azure для PostgreSQL
• Параметры хранилища в Базе данных Azure для PostgreSQL
• Поддерживаемые версии PostgreSQL в Базе данных Azure для PostgreSQL